ソフトウェアのバージョン番号をVCSに保存することは良い習慣ですか？
v1.0.0.100などの製品バージョンは、ソフトウェアの一意の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終的なパッケージ/ビルド/バイナリバージョンを維持する方法は2つあります。
バージョン管理。ファイルのどこかにバージョン番号が保存されています。継続的インテグレーション（CI）ビルドサーバーには、このチェックインされたバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。
環境やビルドパラメータ。これらはバージョン管理の外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは同じ方法で数値を分配して使用しますが、ビルドスクリプトに対してobtain値が異なるだけです（それはprovidedであり、スクリプトに場所を知らせません）ソースツリーを基準にして取得します）。
最初のアプローチの問題は、メインラインのブランチ間でマージを複雑にする可能性があることです。同じソフトウェアの2つの並行リリースをまだ維持している場合、2つのメインラインをマージすると、最後のマージ以降に両方でバージョンが変更されていれば、競合が解決されます。
2番目のアプローチの問題は調整です。 1年前のリリースに戻ると、タグ情報のみに基づいてリリース番号を識別します。
どちらの場合も、バージョン番号の特定の側面がCIビルドの前に認識されていない可能性があります。たとえば、CIビルドは、実際に自動化されたビルド番号である4番目のコンポーネントをプログラムで配置する場合があります（たとえば、ブランチの140番目のビルド）。 VCSのリビジョン番号の場合もあります。
ソフトウェアのバージョン番号に追いつくための最良の方法は何ですか？ 「既知の」部品は常にVCSで保守する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？
現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを使用してバージョン番号を維持しています。 masterブランチにマージする前に、バージョン番号がCIビルドの開始前に適切に設定されているであることに注意する必要があります。 Gitflowワークフローに関しては、バージョン管理がソース管理で追跡されていれば、リリースの準備としてreleaseブランチを作成するときに正しくセットアップされていることを保証できると思います。 QAはこのブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時にmasterへのマージが行われ、リリースのコミットメントを示します。
個人的に、私はオプション3：VCSmetadata、特にタグにバージョン情報を保持することを選択します。
タグに基づいてコミットを一意に記述できるコマンド git describe があるため、Gitを使用すると非常に簡単に実行できます。仕組みは次のとおりです。
- 現在のコミットにタグが付いている場合は、タグの名前を出力します。
- それ以外の場合は、タグが見つかるまで履歴をさかのぼって、次の形式で説明を出力します：
<tag>-<number of commits since the tag>-g<abbreviated commit hash>。 - 作業ツリーにコミットされていない変更がある場合は、
-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行exeを作成しました。ビルド前のイベントでは、ビルド中にteamcityがタグ付けしたビルド番号を取得します。このコマンドラインツールは、ビルド番号を含む1つの定数を持つクラスを自動生成します。バージョン番号の残りの部分：major.minor.patchは、別のファイルの通常の定数です。これらの2つの共有ファイルは、ソリューション内のすべてのアセンブリにリンク（alt + shift-ドラッグ）として含まれています。
このアプローチは、teamcityでコードをビルドしてテストできるほど強力です。 Azureにプッシュして、kuduでビルドし直しますが、dllのバージョンとしてteamcityビルド番号を使用します。