38

Continuous Delivery でのバージョン管理について具体的な質問があります。私は、多かれ少なかれこれであるというグローバルワークフローを理解していると思います:

1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment

バージョン管理についてはどうですか？ビルド バージョンの管理方法

セマンティック バージョニングを使用する Maven ベースのプロジェクトに取り組んでいるとしますmajor.minor.build。

開発者が変更を VCS にコミットし、CI サーバーがビルドを実行する場合、CI サーバーはビルド バージョンをインクリメントし、VCS でタグを作成する必要がありますか?

このビルド バージョンはソース コードに存在しますか? その場合、CI サーバーがプロジェクトの変更 (バージョンの増分) をコミットしたため、VCS にプッシュするたびに、開発者はプロジェクトを更新する必要があります。

少し混乱しており、CD のワークフローを実用的な方法で理解したいと思っています。

4

3 に答える 3

40

一般に、次のものが必要です。

  1. 手動で管理されるバージョン番号。
  2. 任意の数の「参照」番号。

最初のポイントは、semver に関心がある場合、または他のツール/ライブラリの互換性情報を提供する必要がある場合に重要です。新しい「リリース」が何かを壊すかどうかを判断できるのはあなただけです。最も一般的な表示システムは、semver バージョン管理規則に従っています。

2 番目のポイント (「参照」番号) は、重要な場合とそうでない場合があります。通常、複数の CI/CD ビルドのバージョン番号は必要ありません (一般的なすべての CI/CD サービスには、その特定の「ビルド」を参照するビルド バージョン番号 ID があります)。この数字のポイントは、必要に応じて、アーティファクトの関連する CI/CD ビルド/ログをすばやく確認できることです。

2 つ (またはそれ以上) のパーツをマージする方法は?

「バージョン」番号と「ビルド」番号が別々であることは珍しくありません。実際、すべての iOS プロジェクトにはデフォルトでそれがあります。その場合、「バージョン」番号は手動で管理され、別の「ビルド」番号は自動的に管理されます。ビルド番号は、アーティファクトの名前に含めることも--version、バイナリの場合は誰かが情報を取得したときに出力することもできます (例: $ brew info->0.9.5 (git revision 18c48; last commit 2015-11-02)

あるいは、新しいコンポーネントを semver ( ) に追加するか、semverx.x.x.BUILDNUMの最後のコンポーネントを使用するか ( x.x.BUILDNUM- 厳密に増分がある場合はこれをお勧めしませんBUILDNUM)、単にアーティファクトの名前に「ビルド」番号を含めることができます。

これらはすべて可能性です。ケースに最適なものを選択する必要があります。これらの番号の意味を定義し、番号を表示する場所を決定する必要があります (たとえば、--version呼び出しの一部にするか、ファイル名の一部にするか)。

編集：「CIサーバーはビルドバージョンをインクリメントし、VCSでタグを作成する必要がありますか?」に関する質問を反映するために。- 私は決してお勧めしません。CI サーバーにも問題がある可能性があるため、CI プロセスからコードを変更しないでください。何かを誤って上書きする (強制的に押すなど) ことは、非常に危険です。そのため、CI/CD サービスによって公開されているビルド番号を使用する方が適切です。

于 2015-11-20T08:13:46.853 に答える