1

当社のソフトウェアは複数のコンポーネントに分割されています。

msbuild スクリプトは、ビルド スクリプトとバッチ スクリプトを自動化して呼び出します。小さな変更があっても、コンポーネントの毎日のビルドを行っています。チェックインが発生するたびにビルドがトリガーされるように、継続的な統合に移行したいと考えています。

msbuild スクリプトは、コンポーネントのすべての sln ファイルをビルドするように記述されています。継続的インテグレーションでは、変更された sln のみをビルドする必要がありますか?

変更されたアイテムのみをビルドする場合、sln ごとに msbuild を作成する必要がありますか?

teamcity で既存の msbuild スクリプトをそのまま使用できますか?

4

3 に答える 3

5

私は両方を行いましたが、どちらにも長所と短所があります。

増分ビルド (変更されたもののみ)

これは、MSBuild の既定の動作です。Visual Studio でビルドする場合でも、変更された部分のみがビルドされます ([すべて再ビルド] を選択しない限り)。

長所

  • 速いフィードバック ループが速いほど、良い結果が得られます。
  • 毎回ソース管理からすべてをチェックアウトする必要がないため、ビルド サーバー ディスクとネットワークの負荷が軽減されます。これは、負荷の高いビルド クラスターでは重要な場合があります。

短所

  • 考えられるソース管理の問題 ソース ツリーの複雑な名前変更または再構築により、チェックアウトが失敗するという問題がありました。サブバージョンを使用していたので、更新に失敗しました。クリーン チェックアウトを行っていれば、このようなことは起こらなかったでしょう (もちろん、クリーン チェックアウトは、完全な再構築を行う必要があることを意味します)。
  • 誤検知の可能性。ビルド エージェントのソース ファイルを完全に消去せず、ソースから新しいコピーをチェックアウトするケースがありました。誰かがビルド ファイルを変更して、バイナリをテストする前に正しくコピーしないようにしましたが、古いバイナリがまだディスクに残っていたため、それらからテストを実行していました。ビルドは壊れていましたが、古いバイナリ テストを実行していたため、1 週間後に問題を発見するまで、バグが発生したことに気づきませんでした。

完全なチェックアウトと再構築

長所

  • より堅牢毎回白紙の状態から開始するため、ソース管理の更新の問題や誤検出の可能性を排除できます。これにより、以前のビルドがこのビルドに影響を与える可能性がなくなります。

短所

  • はるかに遅いこれには、ソースからの完全なチェックアウトを待つ必要があり、プロジェクトが大きい場合は時間がかかる場合があります。さらに、ソース ツリー全体をゼロから構築する必要があります。
  • ビルド エージェント、ディスク、およびネットワークの負荷が高くなる すべてをチェックアウトして再構築するため、ビルド エージェントの CPU とディスク、さらにはネットワーク (およびソース管理システム) の CPU とディスクにさらに負担がかかります。

3 番目のオプション: 増分チェックアウトと再構築

これは、ソース管理から増分変更のみを取得し、完全な再構築を実行する場合です。

長所

  • 完全なチェックアウトよりも速く、実際にはインクリメンタル ビルドよりもわずかに遅いだけです。通常、ビルド時間は、完全なチェックアウトやテストの実行にかかる時間に比べて短くなります。
  • すべてのソースを再構築するため、多少堅牢になりますが、誤検出が入り込む可能性があります。

短所

  • ソース管理の問題の可能性インクリメンタル ビルドに関する私のコメントを参照してください。
  • 誤検知の可能性Incremental Build に関する私のコメントを参照してください。

どれが最高ですか？

これは、迅速なフィードバック (速度) の必要性と、ネットワークおよびビルド エージェントのリソースの制約とのバランスによって異なります。多くのリソースがあり、迅速なフィードバックと完全な再構築の堅牢性の両方が必要な場合は、2 回構築できます。おそらく、チェックイン時にインクリメンタル ビルドを実行しますが、毎晩完全なチェックアウトと再ビルドを実行します。

于 2012-11-05T04:49:28.573 に答える
1

両方、ある種。スケジュールされた毎日のフルビルドと、日中の増分（ゲートチェックイン）を実行します。

すべては、ビルドが実際にどれだけ大きくて複雑であるかに依存しますが、どちらか一方を使用する場合は、完全に向かってエラーを起こす必要があります。

于 2012-11-02T14:54:09.213 に答える
0

ビルドの粒度がどうであれ、私のバイアスは、そのコンポーネント全体の完全でクリーンなビルドを行うことです。CI ループのビルド時間が過度に長い場合は、そのコンポーネントを相互のバイナリに依存する小さなパーツに分割することを検討してください。その場合、変更されたコンポーネントと、変更されたコンポーネントに依存するその他のコンポーネントをビルドします。.Net の世界では、これらのバイナリ依存関係を管理するために Nuget の人気が高まっていると聞いています。

この戦略については、私のCI 鎮痛シリーズのプラクティス 2 で詳しく説明しています。

于 2012-11-02T14:50:11.723 に答える