連続配信でバージョン管理を構築する

Question

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

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ワークフローを理解したいと思います。一般的に

Answer 1

あなたが持っている必要があります。

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

セマフォを気にする場合や、他のツールやライブラリの互換性情報を提供する必要がある場合は、最初の点が重要です。新しい「リリース」が何かを破るかどうかを知るのはあなただけです。最も一般的な指示システムは、セーバーのバージョン管理ルールに従っています。

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）、使用（x.x.BUILDNUM - 厳密にインクリメンタルなBUILDNUMがある場合はこれをお勧めしません）、または単にアーティファクトの名前に「ビルド」番号を含めてください。

これらはすべて可能ですあなたのケースに最適なものを選んでください。あなたはこれらの数字の意味を定義し、数字をどこに提示すべきかを決めなければなりません（例えば、--version呼び出すか、ファイル名の一部にする必要があります）。

edit：「CIサーバーがビルドバージョンを増やしてVCSでタグを作成する必要がありますか」という質問に反映されますか？ - 私はこれを絶対に勧めません。 CIサーバーにも問題がある可能性があります。コードをCIプロセスから変更しないでください。誤って上書きする（例：力を押して）何かが本当に危険なことができます。そのため、CI/CDサービスで公開されているビルド番号を使用するほうがよいです。