バージョン管理は非常に情熱的で、使いやすいバージョン管理システムを考案するために長い間費やしてきました。質問ですでに述べたことから、1つの重要なポイントを理解したことは明らかです。アセンブリのバージョン番号は製品のバージョンと同義ではありません。1つは技術的に推進され、もう1つはビジネスによって推進されます。
以下では、何らかの形のソース管理とビルドサーバーを使用することを想定しています。コンテキストには、TeamCityとSubversion / Git を使用します。TeamCityは、少数（10）のプロジェクトでは無料で、非常に優れたビルドサーバーですが、他にも完全に無料なものもあります。
バージョン番号の意味
バージョンが1人の人に何を意味するかは、別の人に別の意味があるかもしれません。一般的な構造は、メジャー、マイナー、マクロ、ミクロです。私がバージョン番号を見る方法は、それを2つの部分に分解することです。前半では、メインバージョン（メジャー）とすべての主要な更新（マイナー）について説明します。後半は、いつビルドされ、ソースコードのバージョンが何であったかを示しています。バージョン番号は、API、Webアプリなど、コンテキストに応じて異なる意味でもあります。
Major。Minor。Build。Revision
Revision これは、実際に何が作成されたかを識別するためにソース管理から取得した数です。Buildこれは、ビルドサーバーで特定のビルドを見つけるために使用できる、ますます増加する数です。ビルドサーバーが異なるパラメーターセットを使用して同じソースを2回ビルドした可能性があるため、これは重要な数値です。ビルド番号をソース番号と組み合わせて使用すると、何がどのようにビルドされたかを識別できます。Minorこれは、パブリックインターフェイスに大きな変更がある場合にのみ変更する必要があります。たとえば、それがAPIである場合、消費するコードはコンパイルできますか？メジャー番号が変更されると、この番号はゼロにリセットされます。Major使用している製品のバージョンを示します。たとえば、すべてのVisualStudio 2008アセンブリのメジャーは9で、VisualStudio 2010は10です。
ルールの例外
ルールには常に例外があり、それらに遭遇したときに適応する必要があります。私の最初のアプローチはsubversionの使用に基づいていましたが、最近はGitに移動しました。中央リポジトリを使用するSubversionやSource Safeなどのソース管理には、特定の時点の特定のソースセットを識別するために使用できる番号があります。これは、Gitなどの分散ソース管理には当てはまりません。Gitは各開発マシンにある分散リポジトリを使用するため、使用できる自動インクリメント数はありません。チェックインの数を使用するハックがありますが、見苦しいです。このため、私のアプローチを進化させなければなりませんでした。
Major。Minor。Macro。Build
リビジョン番号がなくなり、ビルドは以前のリビジョンの場所に移動し、マクロが挿入されました。マクロはどのように見えるかを使用できますが、ほとんどの場合はそのままにしておきます。TeamCityを使用しているため、リビジョン番号から失われた情報はビルドで見つけることができます。これは、2つのステップのプロセスがあることを意味しますが、何も失われておらず、許容できる妥協案です。
設定するもの
最初に理解しておくべきことは、アセンブリバージョン、ファイルバージョン、および製品バージョンが一致する必要がないことです。異なる数のセットを使用することは推奨しませんが、依存するアセンブリの再コンパイルを強制されないパブリックインターフェイスに影響を与えないアセンブリに小さな変更を加えると、作業が大幅に楽になります。これに対処する方法は、アセンブリバージョンにメジャー番号とマイナー番号を設定するだけで、ファイルバージョンにすべての値を設定することです。例えば：
- 1.2.0.0（AssemblyVersion）
- 1.2.3.4（FileVersion）
これにより、アセンブリのバージョンが一致しないために既存のコードを壊さないホットフィックスをロールアウトできますが、ファイルのバージョン番号を確認することで、アセンブリのリビジョン/ビルドを確認できます。これは一般的なアプローチであり、アセンブリの詳細を見ると、一部のオープンソースアセンブリで確認できます。
チームリーダーは、重大な変更が必要になったときにマイナー番号を増やす責任を負う必要があります。必要な変更をインターフェイスにロールアウトするが、以前のコードを壊さないための1つの解決策は、現在のコードを古いものとしてマークし、新しいインターフェイスを作成することです。つまり、既存のコードはメソッドが廃止されており、いつでも削除できるが、すべてをすぐに破棄する必要がないことを警告されます。その後、すべてが移行されたときに、廃止されたメソッドを削除できます。
一緒に配線する方法
上記のすべてを手動で行うこともできますが、非常に時間がかかります。プロセスを自動化する方法を次に示します。各ステップは実行可能です。
- プロジェクトのすべてのAssemblyInfo.csファイルから
AssemblyVersionおよびAssemblyFileVersion属性を削除します。
- 共通のアセンブリ情報ファイル（VersionInfo.csという名前）を作成し、リンクされたアイテムとしてすべてのプロジェクトに追加します。
- 「0.0.0.0」の値を持つバージョンに
AssemblyVersionおよびAssemblyFileVersion属性を追加します。
- ソリューションファイルをビルドするMsBuildプロジェクトを作成します。
- ビルドの前に、VersionInfo.csを更新するタスクを追加します。バージョン番号を設定できるAssemblyInfoタスクを含むオープンソースのMsBuildライブラリがいくつかあります。任意の数に設定してテストするだけです。
- ビルド番号の各セグメントのプロパティを含むプロパティグループを追加します。ここで、メジャーとマイナーを設定します。ビルド番号とリビジョン番号を引数として渡す必要があります。
subversionを使用：
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
うまくいけば私ははっきりしているが、多くのことが関係している。質問してください。フィードバックを使用して、より簡潔なブログ投稿をまとめます。