VCSにソフトウェアバージョン番号を保存することをお勧めしますか？

などの製品バージョンは、v1.0.0.100ソフトウェアの固有の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終パッケージ/ビルド/バイナリバージョンを維持するための2つの方法があります。

1. バージョン管理。ファイルはどこかにバージョン番号を保存します。Continuous Integration（CI）ビルドサーバーには、このチェックインバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。

2. 環境および/またはビルドパラメータ。これらはバージョン管理外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは、同じ方法で番号を配布および使用しますが、値の取得方法が異なります（ソースツリーに対する相対位置をスクリプトに知らせるのではなく、ビルドスクリプトに提供されます）。

最初のアプローチの問題は、メインラインのブランチ間でマージが複雑になる可能性があることです。同じソフトウェアの2つの並行リリースを引き続き維持する場合、最後のマージ以降に両方のバージョンが変更されている場合、2つのメインライン間のマージ時に競合を解決します。

2番目のアプローチの問題は、調整です。1年前のリリースに戻ると、タグ情報のみに依存してリリース番号を識別します。

どちらの場合も、CIビルドの前に知られていないバージョン番号の特定の側面があるかもしれません。たとえば、CIビルドは、実際には自動化されたビルド番号である4番目のコンポーネント（たとえば、ブランチ上の140番目のビルド）にプログラムで配置できます。VCSのリビジョン番号でもあります。

ソフトウェアのバージョン番号を把握する最善の方法は何ですか？VCSで「既知の」部品を常に維持する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？

現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを介してバージョン番号を維持しています。masterブランチにマージする前に、CIビルドの開始前にバージョン番号が適切に設定されていることを注意する必要があります。Gitflowのワークフローに関しては、ソース管理でバージョン番号が追跡されていればrelease、リリースの準備でブランチを作成するときに、バージョン番号が適切に設定されることを保証できると思います。QAは、このブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時に、masterリリースへのコミットメントを示すマージが行われます。

個人的には、オプション3を選択します。VCS メタデータ、特にタグにバージョン情報を保持します。

Gitを使用するとgit describe、タグに基づいてコミットを一意に記述することができるコマンドがあるため、非常に簡単に実行できます。仕組みは次のとおりです。

• 現在のコミットにタグが付けられている場合は、タグの名前を出力します。
• それ以外の場合、タグが見つかるまで履歴を逆方向にたどり、次の形式で説明を出力します<tag>-<number of commits since the tag>-g<abbreviated commit hash>。
• workingtreeにコミットされていない変更がある場合は、追加します-dirty。

したがって、リリースビルドを実行していて、コミットにタグを付けている1.2.3場合、出力されます1.2.3。現在1.2.4で作業していて、1.2.3以降4つのコミットを行い、コミットされていない変更がツリーにある場合、出力されます1.2.3-4-gdeadbee-dirty。

これは一意で単調であることが保証され、人間が読むことができるため、バージョン文字列として直接使用できます。確認する必要があるのは、タグの適切な命名規則だけです。

はい。ほとんどのバージョン番号をvcsに保持することをお勧めします。major.minor.patch.buildがあるセマンティックバージョニングsemver.orgを検討する場合、最初の3つはvcsに存在する必要があります。最後の1つは、バイナリが作成される特定のコミットをバックトラックするために使用されるビルドサーバーからの増分番号です。

.NETでこれを容易にするために、gitにコミットされる小さなcmd line exeを作成しました。ビルド前イベントで、ビルド中にteamcityがタグ付けしたビルド番号を取得します。このcmdラインツールは、ビルド番号を含む1つの定数を持つクラスを自動生成します。残りのバージョン番号：major.minor.patchは、別のファイルの通常の定数です。これら2つの共有ファイルは、ソリューションのすべてのアセンブリにリンク（alt + shift-drag）として含まれています。

このアプローチは十分に強力なので、teamcityでコードをビルドしてテストできます。azureにプッシュして、kuduで再度ビルドしますが、teamcityビルド番号はdllのバージョンです。