9

バックグラウンド。私の組織は、Maven、Bamboo、Artifactoryを使用して、継続的インテグレーションプロセスをサポートしています。Artifactoryでのストレージの管理（古いSNAPSHOTビルドのローテーション）とチーム間の統合の最新化（MavenはビルドごとにSNAPSHOTの依存関係の更新を自動的にチェックする）を支援するために、MavenのSNAPSHOT修飾子に依存しています。

問題。私たちが抱えている課題の1つは、SNAPSHOTを使い続けながら、環境から環境へのビルドを正しく促進することです。テスターがバージョン1.8.2-SNAPSHOTを機能テスト環境にデプロイし、Subversionのリビジョン1400にあるとします。また、機能テストに合格したとしましょう。テスターがArtifactoryからパフォーマンステスト環境に1.8.2-SNAPSHOTをプルすることを決定するまでに、開発者はSubversionへの変更をコミットできた可能性があるため、Artifactoryの実際のバイナリは異なる回転数になります。SNAPSHOTビルドを使用するときに、回転数が下から変わらないようにするにはどうすればよいですか？

制約。明らかに、無意識のうちに異なるビルドをデプロイしたくありません。また、機能テストでテストしたパフォーマンステストで正確なバイナリをテストしたいので、ソースから再構築したくありません。

私たちが検討したアプローチ。考えは、バージョンに1.8.2.1400のような4番目のコンポーネントをスタンプしたいということです。ここで、4番目のコンポーネントはSubversionrevです。（副次的な質問として、Mavenプラグインまたはそれを自動的に行う他の何かがありますか？）しかし、そうすると、MavenとArtifactoryはこれらが異なるバージョンであると考えるため、本質的にスナップショット機能が失われます。

スクラムを使用しているため、非常に早い段階（2日目程度など）でテスト環境にデプロイします。SNAPSHOTのメリットが再び失われるため、開発サイクルの早い段階でSNAPSHOT修飾子を削除することは意味がないと思います。

他の組織がこの問題をどのように解決するかを知っていただければ幸いです。

4

3 に答える 3

3

これに戻って、私たちが何をしているかを共有したいと思いました。

基本的に、1.8.2-SNAPSHOT のようなスナップショット ビルドを開発環境にデプロイします。他のチームはこれらのビルドを使用する必要がないため、-SNAPSHOT を残しても問題ありません。

ただし、テスト環境 (機能テスト、システム テストなど) または本番環境にデプロイするビルドには、リビジョンを含める必要があります。例: 1.8.2.1400。これらを「クワッド」と呼びます。テストでクワッドに固執する理由は、問題 (機能、バグ修正など) を特定のリビジョンに添付して、テスターが何をテストすべきかを理解できるようにするためです。本番環境では、テストしたものとまったく同じアーティファクトをデプロイしたいという理由だけで、クワッドをデプロイしていることになります。

とにかく、その情報が誰かに役立つことを願っています。

于 2011-07-01T08:34:32.097 に答える
1

VCS リビジョンのビルド番号をアーティファクトのバージョンに埋め込むのではなく、META-INF/MANIFEST-MFファイルに CI ビルド番号を埋め込みます。

たとえば、Hudson 環境変数を使用してビルドを識別する を参照してください。この記事は Jenkins/Hudson に適用できますが、Bamboo に移植するのは簡単だと思います。

于 2011-07-01T10:29:06.497 に答える
1

スナップショット ビルドに対して「uniqueVersion」を有効にすると、デプロイされたすべてのスナップショットに一意の ID が割り当てられます。これを使用して、環境全体で正しくプロモート ビルドを展開していることを確認できます。

また、補足として、buildnumber-maven-plugin を使用してサブバージョンのビルド番号をアーティファクトに追加できます。

于 2011-03-30T02:35:34.730 に答える