14

開発中にビルド アーティファクトがスナップショット リポジトリに配置されることを理解しています。

製品をテストのために QA に送る必要がある場合、チームはスナップショット リポジトリから取得しますか? それとも、完全なビルドを行い、リリース リポジトリにデプロイして、そこから QA に渡しますか?

また、私のスナップショット リポジトリが各ビルドのすべてのビルド アーティファクトを保持している場合、これは一般的にどのようにクリーンアップされますか? ビルド サーバーから最後の 5 つのビルドを保持していることがわかりましたが、すべてではありませんでした。役立つ場合は Artifactory を使用しています。

4

1 に答える 1

18

意見は異なりますが、私のアプローチは次のとおりです。

スナップショットは開発用です

通常、「使い捨て」ビルドに使用されます。ソースコードにコミットされた変更によってトリガーされ、CI サーバーからそれらを公開します。スナップショット ビルドの目的は、特定のチームから最新のテスト済みアーティファクトを共有することです。チームがお互いに jar を共有している可能性があるため、これは重要です。

このアプローチは、ソース コードを共有するという以前のアプローチよりもはるかに安定しています (別のチームがビルドに失敗した何かをコミットすると、常に問題が発生し、他のチームも同様です)。

スナップショットのクリーンアップ

Nexus を使用してリポジトリを管理しています。Nexus には、定期的にスナップショット リポジトリを消去するように構成できるスケジュールされたタスクがあります。Artifactory にも同様の機能があると思います。

リリース候補は QA 用です

私は QA を顧客への本格的なリリースのように扱います。そういうわけで、私は「リリース候補」という用語を好みます。

リリース候補ビルドとスナップショットの主な違いは、ソース コードが "タグ付け" または "ラベル付け" されていることです (SCM システムの用語によって異なります)。あなたがしているのは、必要に応じてバイナリを便利に再作成できる砂の中に線を引いていることです。

Nexus Professional にはステージング スイートがあります。これにより、開発者は新しいリリースを切り取り、それを一時的な「ステージング リポジトリ」に保持できます。明らかに、一部のリリースはテストに失敗し、その場合はドロップされます。他のグループは、チェーン内の次のグループに昇格するか、パブリック エリアにリリースされます。

リリース管理のこの「プロモーション モデル」を実装するには、いくつかの方法があります。

リリース リビジョンの管理方法

私のリリースでは、次の番号付け規則を使用しています。

<major number>.<minor number>.<patch number>.<build number>

Example:
1.0.0.24

(小規模/単純なプロジェクトの場合、規則を変更してパッチ番号を削除する場合があります)。

Ivy には、リポジトリに既に公開されているものに基づいて、増加するビルド番号を管理するための非常に便利なbuildnumberタスクがあります。

<property name="release.candidate" value="1.0.0"/>
..
<ivy:buildnumber organisation="${ivy.organisation}" module="${ivy.module}" revision="${release.candidate}"/>
..
<echo message="Release revision: ${ivy.new.revision}"/>

release.candidateプロパティは通常、バージョン管理下のプロパティ ファイルに格納されます。このソリューションで私が本当に気に入っているのは、並列ブランチ管理が可能になることです (この質問への回答を参照してください)。

于 2011-12-10T12:51:34.710 に答える