Modular TeamBuilds

Question

私は3つのTFSビルド（2 Devと1 Cert）を持っています。

ビルドをモジュール化して共通アイテムを変更するたびに3つのファイルを編集する必要はありません。

問題は、ビルドフォルダ（TeamBuildTypesの下のアイテム）のみが自動的にチームビルドによって取得されることです。ビルドプロセスでコードを入れて他のファイルを取得することはできますが、それまでには遅すぎます。

ここに私が持っているシナリオがあります。私は一般的な仕事のための "共通の"場所を作る。私はそのファイルに行って変更を加えました。ビルドプロセスがダウンロードを指示するまでファイルがロードされないため、ロードが遅すぎます（インポートは既に行われており、MSBuildプロセスはビルドターゲットをメモリに構築しています）。

ビルドのワークスペースに追加することを考えましたが、ソース取得ターゲット（これも遅すぎます）で取得されます。

私は私がファイルを複製したりないソースコントロールを使用していません解決策を見ることができない...

任意のアイデア？

Answer 1

チームビルド2008では、この問題の解決策として「理想的」ではありません。一般的なものをに解決された$(MSBuildExtensionsPath)のビルドマシンに置き、そこから参照することをお勧めします。

ビルド構成が、あなたは可能性が非常に類似している場合：

1. ポイントビルド定義のすべての単一の構成フォルダに。
2. 共通ビルドロジックをTFSBuild.projに入れます。
3. TFSBuild.projの末尾に<Import Project="TFSBuild.$(BuildDefinitionName).proj" />を追加します。
4. TFSBuildのビルド定義によって異なる構成を追加します。 <BuildDefinitionName>.proj。 Cに解決

Answer 2

あなたの最良のオプションは$でビルドマシン上で共通のものを置くことである（MSBuildExtensionsPath）：\プログラムファイル\ MSBuildの

私はアイデアを嫌います「マジック」の場所に依存することのあなたは自動的にチームビルドによって取得される（TeamBuildTypes下）ビルドフォルダ内

項目のみ...ちょうど同期してビルドスクリプトを維持するために第二の展開+ QAプロセスを必要としてしまいます。

はちょっとラメ、確かに、私はそれが実際には大きな限界であることが判明していません。

$/TeamProject 
    |- Dev 
     |- Module1 
     |- Module2 
     ... 
     Solution1.sln 
     Solution2.sln 
     |- TeamBuild 
      |- 3rdparty 
       MSBuild.Community.Tasks.dll 
       MSBuild.Community.Tasks.targets 
       RandomScriptOffTheWeb1.targets 
       ... 
      |- SrcSrv     
       srcsrv.ini 
       ... 
      |- SymStor 
       dbghelp.dll 
       ... 
      Common.targets 
      TFSBuild.proj 
      TFSBuild.Common.targets 
      TFSBuild.Config1.targets 
      ... 
      UtilityScript1.ps1 
      ... 
    |- Main   
     ... 
     |- TeamBuild 
     ... 
    |- Release 
     ... 

Common.targetsはすべて* .csproj（など）ファイルによってインポートされます。ここに私のTeamBuildフォルダに簡略化され外観があります。サードパーティのすべてのタスクをインポートし、さまざまなグローバルプロパティ/アイテムを初期化し、参照パスを設定します。

TFSBuild.projはCommon.targetsをインポートし、次にTFSBuild.projをインポートして、$（BuildDefinition）をコンディショニングしてconfigファイルの1つをインポートします。そうすることで、より具体的なものは、タスク/プロパティ/ etcを、必要に応じてあまり特定のファイルから上書きすることになります。それでも、この短いファイルは、私が限られた気がする1つの場所です：ビルド名をプログラムでビルド名をファイル名にマップする方がはるかに良いですが、MSBuildは[実行時]ターゲットに設定されたプロパティに依存します。

TFSBuild.Config * .targetsファイルはほとんどの場合、プロパティのみを設定します。 「本当の」仕事はありません。これには、私がパラメータ化したいチームビルドプロパティと、カスタムターゲット（別の場所で実装された）がどのように動作するかを制御するプロパティが含まれます。

TFSBuild.Common.targetsは、最も長いファイルです。ここではすべてのチームビルドプロパティを適切なデフォルトで設定し、AfterDropBuildのようなターゲットをオーバーライドし、Config *ファイルに設定されているものに基づいて条件付きで実行する自分のカスタムターゲットをたくさん定義します。

注：私は明らかにrecursive download optionを持っていますが、厳密には必須ではありません。サブディメンションをサブフォルダに分割することは、何よりも美学にとって重要です。