web-dev-qa-db-ja.com

継続的デリバリーでのバージョン管理の構築

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でタグを作成する必要がありますか?

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

私は少し混乱しています。CDのワークフローを実際的な方法で理解したいと思います。

26
Héctor

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

  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に追加する(_x.x.x.BUILDNUM_)、semverの最後のコンポーネントを使用する(_x.x.BUILDNUM_-厳密にインクリメンタルなBUILDNUMがある場合、これはお勧めしません)アーティファクトの名前に「ビルド」番号を含めるだけです。

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

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

25
Viktor Benei