TeamCityを使用したアセンブリのバージョン管理

StackOverflow https://stackoverflow.com/questions/1223245

質問

SVNとTeamCityビルドサーバーを使用するC＃/ VB.Netプロジェクトに取り組んでいます。十数個のアセンブリがビルドによって生成されます。アセンブリのバージョンを制御して、それらがすべて一致し、TeamCityビルドラベルにも一致するようにします。

のビルドラベルを使用するようにTeamCityを構成しました

  

Major.Minor。{Build}。{Revision}

MajorとMinorが手動で設定する定数である場合、{Revision}はチェックアウト時にSVNリポジトリバージョンによって決定され、{Build}はTeamCityの自動インクリメントビルドカウンターです。したがって、ビルドラベルの例は次のようになります

  

2.5.437.4423

すべてのアセンブリバージョンがTeamCityビルドラベルと一致するようにするには、どのようなテクニックをお勧めしますか？

役に立ちましたか？

解決

CruiseControl.netとSVNを使用しています。私たちはそれを他の方法で運転します。 MSBuildスクリプトで MSBuildCommunityTasks バージョンタスクを使用してCIビルドのバージョン番号を増やし、そのバージョンを使用しています。ソースコードにタグを付ける番号。

編集： MSBuildターゲットの詳細を要求しました...
CIビルド用であり、開発者ビルド用ではない別のスクリプトを使用します。スタジオがプロジェクトファイルとして使用するMSBuildファイルでさまざまなターゲットを使用しようとしましたが、これは頭痛の種になり、スタジオが生成しているファイルを手動で編集する必要がありました。
MSBuildファイルの構造は非常に単純です：

  1. 余分なピースをインポート

    <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
    <!-- contains some variables that set project names, paths etc. -->
    <Import Project="Properties.msbuild"/>

  2. BeforeBuild：新しいバージョン番号を設定し、AssemblyInfoファイルを書き換えます

    <Version VersionFile="$(VersionFile)" BuildType="None" RevisionType="Increment">
      <Output TaskParameter="Major" PropertyName="Major" />
      <Output TaskParameter="Minor" PropertyName="Minor" />
      <Output TaskParameter="Build" PropertyName="Build" />
      <Output TaskParameter="Revision" PropertyName="Revision" />
    </Version>

    <!--Modify Assembly Info-->
    <AssemblyInfo CodeLanguage="CS"
    OutputFile="Properties\AssemblyInfo.cs"
    AssemblyTitle="$(TargetAssembly)"
    AssemblyDescription="$(AssemblyDescription) svn:@(SanitizedSvnUrl) revision:$(SvnRevision)"
    AssemblyCompany="Your company name"
    AssemblyProduct="Name of product"
    AssemblyCopyright="Copyright © your company 2009"
    ComVisible="false" Guid="$(WindowGuid)"
    AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)"
    AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)"
    Condition="$(Revision) != '0' " />

  3. ビルド：リリースモードで実際のプロジェクトファイルMSBuildスクリプトをビルドします

  4. AfterBuild：ユニットテストプロジェクトを実行し（次の手順で破損したビルドのタグを作成しないように）、SvnInfoタスクといくつかのRegexReplaceタスクを使用して、パスとタグ名で変数を設定します。 SvnCopyタスクを使用してタグを作成します。

<SvnCopy UserName="username"
Password="password"
SourcePath="@(SvnTrunkPath)"
DestinationPath="@(SvnTagsPath)/BUILD-$(TargetAssembly)-$(Major).$(Minor).$(Build).$(Revision)" Message="Tagging successful build" />

他のヒント

TeamCityのAssemblyInfoパッチャービルド機能を使用することをお勧めします。

http://confluence.jetbrains.net/display/TCD65/AssemblyInfo+Patcher

VisualStudioからプロジェクトを作成し、BuildStepsページでビルド機能を構成します（ http://confluence.jetbrains.net/display/TCD65/Adding+Build+Features ）、デフォルトのAssemblyInfo.csファイルを保持している限り機能します。

このアプローチは私にとって非常に効果的です。

利点：

  • 開発者は自分のマシンでソリューションを構築できます。
  • .slnまたは.csprojファイルに触れる必要はありません。動作します。
  • TeamCity変数を使用すると、バージョン番号を他のプロジェクトのバージョンなどに簡単に一致させることができます。

欠点：

  • ビルドスクリプトがないため、TeamCityから別のCIサーバーに簡単に切り替えることはできません（ただし、CIサーバーを切り替えることはORMまたはデータベースを切り替えるようなものです。

ハミッシュの答えは受け入れられた答えのままにしておきますが、完全を期すために、最終的に採用したアプローチを文書化する価値があると思いました。

私はTeamCityで2つの個別のビルド構成を維持しています。1つはCIビルドで、もう1つは変更があった場合（または手動で）毎週実行されるビルドで、公式リリースビルドです。ビルドはおそらくエンドツーエンドで40分かかるため、2ビルドアプローチを採用しました。開発者が変更をコミットするときに、ビルドの問題について迅速なフィードバックを得たいと思いました。したがって、CIビルドはフルリリースビルドのサブセットですが、すべてのコードをビルドします。バージョン管理も2つのビルドで異なります：

  • CIビルドにはバージョン番号{Major.minor.BuildCounter.SvnRevision}があります
    • BuildCounterは0から始まります
    • svnリポジトリにタグ付けしません
  • Weekly / Releaseビルドには同様のバージョン管理システムがありますが、
    • ビルドカウンターは（メジャー* 1000）で始まるため、メジャーが「8」の場合、ビルドカウンターは8000から始まります。
    • svnリポジトリに「Build_ {Version}」というタグを作成します

このややarbitrary意的な選択の理由は、CIビルドとリリースビルドを明確かつ単純に区別できるようにするためです。

AssemblyVersionInfoというソリューション全体のファイルがあり、ソリューション内のすべてのプロジェクトに含まれています（ソフトリンクされています）。このファイルには（本質的に）これが含まれています：

using System.Reflection;
// Revision and Build both set to 9999 indicates a private build on a developer's private workstation.
[assembly: AssemblyFileVersion("6.0.9999.9999")]        // Win32 File Version (not used by .NET)

すべての開発者ビルドは、同じ静的で容易に識別可能なバージョン番号を使用します。これは、バージョン管理の競合において開発者のファイルが優先されるように、ビルドサーバーによって生成されるものよりも大きい番号です。

ビルドサーバーで、MSBuildコミュニティタスクを使用して、デフォルトのコンテンツを上書きする新しいAssemblyVersionInfoファイルを生成します。 TeamCityビルド文字列を新しいバージョンとして使用します。このようにして、次の3つの状況を簡単に区別できます。

  • 開発者のワークステーションで実行されるプライベートビルド
  • ビルドサーバーで実行されたが、リリースされるべきではないCIビルド
  • Svnリポジトリでタグ付けされた公式に承認されたリリースビルド

別の工夫として、AssemblyFileVersionではなくAssemblyVersionを設定していることに注意してください。アセンブリのバージョンを 'Major.Minor.0.0'の静的な固定バージョン文字列に強制します。これは、バージョン管理の問題を心配することなく、バグ修正リリースを発行できるようにするためです。 AssemblyFileVersionを使用すると、アセンブリのIDの一部ではなく、ユーザーがどのビルドをインストールしたかを把握できます。

これはすでに受け入れられている回答ですが、使用したアイデアを追加したいと思います。

大規模なプロジェクトの場合、更新するアセンブリ情報ファイルが多数存在する可能性があり、絶え間ないリファクタリングでは、更新する必要のある新しいファイルをビルドスクリプトが認識しないというリスクが常にあります。

このため、実際のバージョンの定数を定義する簡単なコードファイルを作成し、すべてのプロジェクトがこの定数とアセンブリ情報ファイルを継承します。その後、ビルドスクリプトは1つのファイルを更新するだけで済みます。

ここでのもう1つの利点は、多くのファイルを調べたり変更したりする必要がないため、これによりビルドプロセスが多少高速化されることです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top