7

Team Foundation Build Server の実装でパフォーマンスの問題が発生しており、速度を上げる方法についてのアイデアが不足しています。いくつかのステップ (SkipClean、SkipLabel、SkipInitializeWorkspace) でパフォーマンスを向上させるために、いくつかの PropertyGroup 要素を既に追加しましたが、問題を修正するには大幅な再構築が必要だと思います。セットアップは次のとおりです。

  • それぞれが大きく異なる約 40 の Web アプリケーションがありますが、多数の共有アセンブリから実行されます。
  • これらの Web アプリケーションにはそれぞれ独自のソリューションがあります。
  • これらの Web アプリケーションごとに、約 10 ～ 25 個の共有アセンブリが参照されます。
  • トランクへのチェックインごとに起動されるすべてのソリューションを含むビルド定義が存在します。

そして、これが私たちが直面している基本的な問題です

  • ビルド中に、一度ビルドしてアプリごとに使用するのではなく、参照された回数だけ各共有アセンブリをビルドします。
  • ドロップ ディレクトリのファイル コピー時間は非常に遅いです。ネットワーク共有を介する必要があり、ローカル パスを使用しません。
  • 非常に多くのビルドごとに、1 つ以上の出力ファイルが「ロック」され、コンパイルが正常であってもビルドが中断されます。
  • 別のビルド定義も試しましたが、そうすると、Get Latest バージョンで別のワークスペースを強制的に取得することになります。ビルド サーバーには、ビルドするトランクの 1 つのバージョンが含まれている方がよいでしょう。

過去数か月間、無気力に屈してこの問題を無視してきましたが、現在、ビルド時間は 1 時間から 1 時間半を超えています。

私はクルーズコントロールを学び、より優れたコントロールのためにクルーズコントロールに切り替えるという考えをいじっています. それに同意しない人はいますか？

どんな助けでも大歓迎です。ありがとう！

4

4 に答える 4

3

これが私が行ったことで、ビルドを 9 分に短縮しました。私がコンパイルしているプロジェクトの量については、それで問題ありません。

  • すべての共有ライブラリとすべての Web を含むソリューションを作成しました。レガシ コードや複数の場所に保存されていた多数の参照を修正する必要があったため、このステップでは多くの余分な作業が必要でした。
  • 最終的に最も時間を節約できたのは、すべての出力ファイルのネットワーク コピーではなく、ファイル システムの移動を実行したことです。ドロップ場所は実際にはビルド サーバー上にあるため、これは理にかなっています。

移動を実行するには、TFSBuild.proj ファイル内の CoreDropBuild ターゲットをオーバーライドするだけです。

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
             <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>    
</Target>
于 2008-12-09T13:05:17.047 に答える
2

まず、すべての Web アプリが同じチーム プロジェクトに含まれているように聞こえます。その場合は、それらを論理的なグループに分割します。通常、1 つのチーム プロジェクトは 1 つの配置モデルで構成する必要があります。

次に、共有アセンブリを独自のチーム プロジェクトに分割します。移動したら、いくつかの選択肢があります。ソースまたはコンパイル済みの DLL を、それらを必要とするチーム プロジェクトに分岐できます。それらは独自の単体テストを持つことができ、チーム ビルドを拡張して、成功したテストで自動的にマージすることができます。

要約すると、ビルド戦略を簡素化する必要があります。

于 2008-11-21T20:23:15.047 に答える
1

すべての Web アプリですべてを構築する必要があるでしょうか? 共有アセンブリが変更されていない場合、それらを何度もビルドする必要はありません。

ここに考えがあります：

  1. すべての Web アプリに独自の \lib フォルダーを持たせます。
  2. すべての共有アセンブリを lib フォルダーに配置します。
  3. Web アプリがローカルの lib フォルダーから共有アセンブリのみを参照できるようにします。
  4. すべてをチェックインします。

これで、何かが変更されない限りビルドは開始されなくなり、ビルドには共有アセンブリが含まれなくなります。

  • すべての共有アセンブリを含む中央フォルダーが必要です。
  • ここでの変更は、すべてのローカルの \lib フォルダーに反映されます。
  • 最後に、共有アセンブリが変更されるたびに、中央のフォルダーにコピーする必要があります。

ここでのアイデアは、中央のフォルダーのみを認識する共有アセンブリ プロジェクトを作成することです。これにより、ビルドをコピーするために必要なビルド後のアクションが簡素化されます。

中央フォルダーは、すべての参照 Web アプリに変更がコピーされるように管理する必要があります。

于 2008-11-23T22:04:52.360 に答える
0

CruiseControl の提案に関する個人的な経験から言えば、これは継続的インテグレーションの「フレームワーク」であることを思い出してください。すぐにすべての問題を解決できるわけではありません (コンポーネント化されたビルド、コンポーネントの変更ごとに起動する、シリアル化されたビルドは、物事をより良くします)。思い通りにするには、かなりの構成 (および場合によってはカスタマイズ) が必要になるため、ある程度の時間を投資する準備をしてください。もちろん、ビルド時間が短縮されれば、長期的には莫大な利益を得ることができます。これ以上問題を無視できない場合は、より良い CI ソリューションに時間を投資する価値があります。

ただし、CI の取り組みは、実施しているポリシーと同じくらい効果的であることに注意してください。バージョンのラベル付け、リリース、依存関係、バイナリのベータ リリース、ビルドのアーカイブなど、当時は考慮していなかった多くの問題に関して、大きなポリシーの空白がありました。

また、少なくともいくつかのリソースを維持するために専念する準備をしてください。これはフルタイムの仕事ではありません (継続的なプロセス改善を生み出すので、私はそれをするのが大好きです)。私たちのカスタマイズにより、最初の製品の 2 時間のモノリシック ビルドから、約 20 分以内に複数のマシンで並行してビルドされる 20 個の製品の 400 を超えるコンポーネントに到達したので、それだけの価値があります。

于 2008-11-21T22:23:02.030 に答える