[解決済み] アセンブリのバージョン番号を管理するためのベストプラクティス/ガイダンス

質問

.NETアセンブリの3つの異なるアセンブリバージョン番号を管理する方法について、ポインタ、提案、さらには指示を探しています。 製品バージョンは最も単純で、これは通常ビジネスによって決定されるように思われます。 そして、ファイルバージョンは、デプロイメント間のバージョン管理のためにあるように思われ、実際のアセンブリバージョンは出荷時にのみ使用されます。

そこで、ファイルバージョンのビルド番号とリビジョン番号を自動的にインクリメントし、最終リリースでは、現在のファイルバージョンをアセンブリバージョンにコピーすることを考えています。 この製品は実稼働していますが、まだ開発中で、小さな会社で変更管理インフラがないような状況です。

解決方法は？

バージョン管理は、私が非常に情熱を注いでいることであり、使いやすいバージョン管理システムを考え出すのに長い時間を費やしてきました。ご質問の内容から、あなたが1つの重要なポイントを理解されていることは明らかです。一方は技術的なものであり、もう一方はビジネスによるものです。

以下では、何らかの形でソース管理およびビルドサーバーを使用していることを前提に説明します。文脈上、私たちは チームシティ とSubversion/Gitがあります。TeamCityは少人数(10人)のプロジェクトであれば無料で利用でき、非常に優れたビルドサーバーですが、他にも完全に無料のものがあります。

バージョン番号の意味

ある人にとってのバージョンの意味は、別の人にとっては違うかもしれませんが、一般的な構造は、メジャー、マイナー、マクロ、マイクロです。私は、バージョン番号を2つの部分に分けて考えています。前半は、メインバージョン（メジャー）と主要なアップデート（マイナー）を記述します。後半は、いつ作られたのか、ソースコードのバージョンはどうなっているのかを示しています。また、バージョン番号は、APIやウェブアプリなど、文脈によって異なる意味を持ちます。

Major . Minor . Build . Revision

• Revision これは、ソース管理から取得した番号で、何を識別するためのものです。 が実際にビルドされました。
• Build これは増え続ける番号で、これを利用して ビルドサーバー上の特定のビルド。 これは重要な数字です。 ビルドサーバーは、同じ ソースは2回、異なるセットで パラメータを使用します。ビルド番号と ソース番号と合わせて 何がビルドされたかを特定することができます。 といった具合に。
• Minor これは、重要な変更があった場合のみ変更する必要があります。 パブリックインターフェース 例えば、もしそれが APIを消費するコードは、まだ はコンパイルできるのでしょうか？この数値は、Majorの数値が変更されたときにゼロにリセットされるべきです。
• Major は、どのバージョンの 製品を使用しています。例えば すべてのVisualStudio 2008のメジャー アセンブリは 9 で、VisualStudio 2010 は10です。

例外規定

ルールには常に例外があり、その都度適応していかなければなりません。私の当初のアプローチは、subversionを使うことを基本としていましたが、最近はGitに移行しています。subversionのようなソース管理、中央のリポジトリを使用するソースセーフは、ある時点から特定のソースのセットを識別するために使用できる番号を持っています。Gitのような分散型ソース・コントロールの場合は、そうではありません。Gitは、各開発マシン上にある分散リポジトリを使用するため、自動的に増加する番号はありません。このため、私は自分のアプローチを進化させなければなりませんでした。

Major . Minor . Macro . Build

リビジョン番号は消え、ビルドはリビジョンがあった場所に移動し、マクロが挿入されています。マクロの使い方は自由ですが、私はほとんどの場合、そのままにしています。TeamCityを使用しているため、リビジョン番号から失われた情報はビルドで見つけることができ、2段階のプロセスがあることを意味しますが、私たちは何も失っておらず、許容できる妥協点です。

設定する内容

まず理解していただきたいのは、Assembly Version、File Version、Product Versionは一致する必要はないということです。私は異なる番号のセットを持つことを推奨しているわけではありませんが、依存するアセンブリの再コンパイルを強制されないように、パブリックインターフェースに影響しないアセンブリに小さな変更を加える場合、生活がずっと楽になります。私は、アセンブリのバージョンではメジャーとマイナーのみを設定し、ファイルのバージョンではすべての値を設定する方法でこれに対処しています。例えば、以下のような感じです。

• 1.2.0.0 (アセンブリバージョン)
• 1.2.3.4 (ファイルバージョン)

これにより、アセンブリのバージョンが一致しないために既存のコードを破壊することなく、ホットフィックスをロールアウトする能力が得られますが、ファイルのバージョン番号を見ることによってアセンブリのリビジョン/ビルドを確認することができます。これは一般的な方法で、オープンソースのアセンブリでアセンブリの詳細を見ると分かることがあります。

チームリーダーであるあなたは、ブレークチェンジが必要な場合、マイナー番号をインクリメントする責任を負う必要があります。インターフェイスに必要な変更を加えつつ、以前のコードを壊さないようにするための1つの解決策は、現在のインターフェイスを時代遅れのものとしてマークし、新しいインターフェイスを作成することです。これは、既存のコードにそのメソッドが廃止され、いつでも削除される可能性があることを警告するものですが、すぐにすべてを破壊する必要はありません。そして、すべてが移行されたときに、廃止されたメソッドを削除すればよいのです。

配線方法

上記をすべて手動で行うこともできますが、非常に時間がかかるので、以下の方法で自動化します。各ステップは実行可能です。

• を削除します。 AssemblyVersion と AssemblyFileVersion 属性を、すべてのプロジェクトの AssemblyInfo.cs ファイルから削除します。
• 共通のアセンブリ情報ファイル（VersionInfo.csと呼ぶ）を作成し、すべてのプロジェクトのリンク項目として追加します。
• 追加 AssemblyVersion と AssemblyFileVersion 属性を、バージョンに "0.0.0" の値で設定します。
• ソリューション・ファイルをビルドするための MsBuild プロジェクトを作成します。
• ビルドの前に、VersionInfo.csを更新するタスクを追加します。オープン・ソースのMsBuildライブラリには、バージョン番号を設定できるAssemblyInfoタスクが含まれているものが多数あります。任意の数値を設定して、テストしてください。
• ビルド番号の各セグメントに対応するプロパティを含むプロパティグループを追加します。ここで、メジャーとマイナーを設定します。ビルド番号とリビジョン番号は、引数として渡す必要があります。

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>

私が明確であることを望みますが、多くのことが関係しています。質問があればどうぞ。フィードバックがあれば、より簡潔なブログ記事を作成するために利用させていただきます。

• コンパイル済みアセンブリのバージョン番号
• MSBuild 拡張パック
• TeamCity