2011-10-19 19 views
2

私はTeamCity 6.5.4を使用しており、同じ展開パッケージに対して3つのビルド構成が必要です。私は3つのビルド構成全体にバージョン番号を残しておき、その番号を使用してアセンブリのバージョン、vcsタグ、nuspecファイルなどをバージョンアップすることができます。ビルドステップとビルド構成全体のバージョン番号を固定

ここには構成と希望のバージョン番号があります:

Configuration  | Version 
-------------------|--------- 
CI/Nightly Build | 1.1.* 
Minor Release  | 1.*.0 
Major Release  | *.0.0 

TeamCityは、構成ごとに別々のビルドインクリメンタを使用しているようです。つまり、メジャーリリースまたはマイナーリリースがあるたびに、後続のすべての設定で永続的な値(1)を手動で更新する必要があります。私はプログラマであり、私は怠け者です。私は1つのボタンが私のためにすべてをやりたい。

ビルド番号を、依存するスナップショットを持つ構成のビルドステップで永続化する例がありますが、これは同じ構成でのみ機能します。

Autoincrementerプラグインは、のID番号を毎に更新します。これは数値の変更(*)では問題ありませんが、永続化された値(1)の参照にはあまり適していません。

ビルド構成全体にわたって永続化できるファイルまたは変数にそのバージョンを読み書きできるようにするために、ネイティブまたはプラグイン経由のTeamCityの方法はありますか?

答えて

1

ありがとうございます。私は、リモートXMLのマニフェストファイルにアセンブリメタデータを保持する私のMSBuildスクリプトで使用するカスタムターゲットのセットを書くことを選択しました。新しいTeamCityプロジェクトが作成されると、ビルドスクリプトはInitターゲットを呼び出して、未処理のテンプレートから新しいマニフェストファイルを作成します。

<Copy SourceFiles="@(ManifestTemplate)" DestinationFiles="@(ManifestTemplate->'$(ManifestFile)')" Condition="!Exists('$(ManifestFile)')" /> 

MSBuild Extentionsパックを使用して、マニフェストファイルのバージョン情報などの属性を読み込みます。

私はTeamCityのビルド構成をCI、テスト、マイナーリリース、メジャーリリースに分けて、それぞれ異なるイベントをトリガーしています。プロジェクトビルドスクリプトの対応するターゲットから、DependsOnTargets属性に新しいターゲットを追加して、カスタムターゲットを呼び出して適切なバージョン番号を更新し、マニフェストファイルに保存します。バージョンの更新を処理するためのカスタムターゲットで

<Target Name="Test" DependsOnTargets="IntializeBuildProject;Build-UpdateVersion-Build"> 
<MSBuild Projects="$(SolutionFile)" Targets="Rebuild" Properties="Configuration=$(Configuration)" /> 
<TeamCitySetBuildNumber BuildNumber="$(PackageVersion)" /> 

コード:

<MSBuild.ExtensionPack.Science.Maths TaskAction="Add" Numbers="$(PackageVersionBuild);1"> 
    <Output PropertyName="PackageVersionBuild" TaskParameter="Result"/> 
</MSBuild.ExtensionPack.Science.Maths> 
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="UpdateElement" File="$(ManifestFile)" XPath="/Package/Version/Build" InnerText="$(PackageVersionBuild)"/> 

このファイルには、このようにチームシティーのビルド番号を無視して、バージョンや他のメタデータの永続性を処理します。 XMLメタデータファイルは集中管理されているので、Nuspec、AssemblyInfo、およびWiX Installerのメタデータを入力したり、サービスメッセージを通じてバージョンやその他の関連情報をTeamCityに渡したりすることができます。

パッケージの詳細が変更された場合、私のチームがファイルの内容をリモートで編集できるように、単純なMVC Webインターフェイスを追加しました。これで、著作権情報や特定のビルドプロジェクトのその他のメタデータなどの情報を更新する場所が1つだけになりました。また、私はTeamCityビルド構成へのアクセスを許可せずに、非devの人々にMVCサイトへのアクセス権を与えて、ブランディング情報を更新することもできます。

TeamCityにバージョンを中継するために使用されるサービスメッセージを除いて、TeamCityと結合されたサービスメッセージはほとんどありません。私はカスタムターゲットに機能を持たせ、別のビルド管理ソリューションに移行する機会を逃してTeamCityからスクリプトを削除するのが好きです。そのため、私はTeamCityプラグインを構築する時間を取ることを想定していませんが、近いうちにブログシリーズが出る可能性があります。

興味のある方は、より多くのコードと詳細な説明をお寄せください。

3

あなたはbtx後者のBTのIDであるdep.btx.build.numberを用い依存(アーティファクト/スナップショット)の構成のビルド番号を参照することができます。ビルド番号を取得したら、設定で実行中のスクリプトにビルド番号を渡し、スクリプト内のビルド番号を解析し、service messagesをスクリプトからTeamcityに送信してビルド番号を設定します。この解析と設定番号をスクリプトの最初のステップ/ビルドステップの最初のステップとして行います。

+0

ご回答いただきありがとうございます。これは、依存する成果物を持つ同じビルド構成で正常に動作します。私がここで持っているのは、3つの異なるステップセットを持つ3つの別々のビルド構成です。私はバージョン番号を構成全体に保持し、ステップを構築する必要はありません。 –

+0

さらに明確にするために、CIビルドはvcsのコミット時に行われ、たとえばバージョン2.19.123を追い出すべきです。マイナーリリースビルドは手動で実行され、バージョン2.20.0を追い出す必要があります。メジャーリリースビルドも手動で実行され、バージョン3.0.0を追い出す必要があります。このすべてが起こるためには、バージョンを保存して以降のビルドのために参照できる中心的な場所がなければなりません。 –

+0

@DaveBaxter - あなたは私の答えを理解していません。私は同じビルド構成について話しているわけではありません。私は構成全体を話している。もう一度それを読んでみてください。 – manojlds

0

はい、これを簡単に行うためのプラグインを作成できます。私の自動インクリメントビルド番号(構成間)プラグインを使用して、必要に応じて変更することができます。ビルド番号は、TeamCityの管理画面から設定可能なテキストファイルに保存されます。

http://github.com/ornatwork/tc_plugins/tree/master/unique

あなたが必要な場合は、それを変更する方法を入力のために私を打つことができます。

+0

問題を処理するためにこのようなプラグインを書くのを見ているだけでした。私は**知っていました**私はこのタイプのセットアップが必要な唯一の人ではありませんでした。あなたがすでに持っているコードを見てみましょう。自分の環境に必要な変更があるかどうかを確認します。ありがとう! –

関連する問題