web-dev-qa-db-ja.com

CIビルドパイプラインからNPMパッケージを公開し、バージョン管理を自動化する方法は？

木の後ろの森が見えないようです。 NPMパッケージをビルドして公開する単純なCIパイプラインが必要です。私はappveyorを使用していますが、私の問題はそれに固有のものではないと思います。 CIスクリプトで次のような処理を実行したいだけです。

git clone "https://git_repo_url" .
npm run build
npm run test
npm version patch --git-tag-version
npm publish -tag beta

問題は：

  • npm version patchステップを実行しない場合、公開はfeed already contains the package 'abc' at version 'x.y.z'エラーで失敗します。

  • その手順を実行した場合、新しいコミット（バージョンの変更）をgitリポジトリにプッシュする必要があります。そうしないと、次に私または他の誰かがビルドしたときに、上記のように失敗します。それでも、バックエンドパイプラインでgit Pushを実行するのは適切だとは思いません。

  • 最後に、このCIスクリプトが公開せずにNPMパッケージをビルドするだけの場合、それに依存している他のプロジェクトでどのように使用しますか？

これを行う業界標準の方法は何ですか？

たとえば、別のプロジェクトでパッケージの非プロダクション機能バージョンをテストする必要がある場合、生成された一意のsemverでパッケージのpackage.jsonにパッチを当てるようにCIスクリプトを作成する必要がありますか？互換性のあるバージョン（コミットせずに）にして、gitブランチ名と一致するnpmタグを付けて公開しますか？それは良い考えですか？

javascriptnode.jsnpmversion-controlcontinuous-integration
6
avo

私は、通常の開発サイクル中にCIを使用して内部/リリースごとのNPMパッケージを公開するためのDevOpsのベストプラクティスについて学ぶことに非常に興味があります。

通常、プロジェクトのメンテナは、プロジェクトに加えられた機能や変更に基づいて、バージョンをバンプします。

例えば：

  • 変更が重大な変更（非バックワード互換）である場合、メンテナはmajorバージョンをバンプします
  • 変更が新しい機能（ヘルパー関数、リファクタリングなど）である場合、メンテナはマイナーバージョンをバンプします

patchバージョンには多くのアプローチがあります。ここに2つあります：

  1. patch番号をバンプしてリポジトリにコミットするgit pre-Pushフック。プロジェクトのソースコードを変更するbuild\ciシステムを排除します。
  2. build = ciシステムで ビルド番号 をpatch番号として使用し、patchバージョンがリポジトリにコミットされました
1
Mr.