5

統合サーバーをセットアップしていますが、ビルドを完了するために複数のタスクを使用することに関する最善のアプローチについて疑問があります。すべてを 1 つの大きなジョブに設定するか、小さな依存ジョブを作成するのが最善の方法ですか?

4

7 に答える 7

3

あなたは間違いなくタスクを分割したいです。これは、ステップごとに異なるターゲット（タスク）を持つCruiseControl.NET構成の良い例です。また、ほとんどカスタマイズせずにプロジェクト間で共有できるcommon.buildファイルを使用します。

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

于 2008-08-27T12:27:58.113 に答える
1

私が好むアプローチは、次のセットアップです (実際には、.NET プロジェクトにいると仮定します)。

  • CruiseControl.NET。
  • 個々のステップごとの NANT タスク。代替 CC テンプレートの Nant.Contrib。
  • 単体テストを実行するための NUnit。
  • NCover を使用してコード カバレッジを実行します。
  • 静的分析レポートの FXCop。
  • ソース管理のための Subversion。
  • ビルドや失敗などの通知を取得するために、すべての開発ボックスで CCTray または同様のものを使用します。

多くのプロジェクトでは、チェックイン時にさまざまなレベルのテストやアクティビティが行われることがわかります。ビルド後、開発者がチェックインでビルドを壊したかどうかを確認できるようになるまでに、時間がかかる場合があります。

これらの場合に私が行うことは、3 つのビルド (または 2 つ) を作成することです。

  • CI ビルドはチェックインによってトリガーされ、クリーンな SVN の取得、ビルド、軽量テストの実行を行います。理想的には、これを数分以下に抑えることができます。
  • CI と同じことを行いますが、より包括的で時間のかかるテストを実行する、より包括的なビルド (変更があった場合) は 1 時間ごとになる可能性があります。
  • すべてを実行し、アセンブリのコード カバレッジと静的分析を実行し、毎日の MSI パッケージなどをビルドするための展開手順を実行するオーバーナイト ビルド。

CI システムで重要なことは、それが有機的であり、常に調整されている必要があるということです。CruiseControl.NET にはいくつかの優れた拡張機能があり、ステップのビルド タイミングなどをログに記録してグラフ化し、履歴分析を行うことができるため、ビルドを継続的に微調整してビルドをスムーズに保つことができます。ビルド ボックスを使用すると、作業時間の 5 分の 1 を忙しくさせて作業を停止させてしまう可能性があることを、マネージャは受け入れがたいと考えています。

于 2008-08-27T13:05:02.703 に答える
1

Nant ビルド スクリプトで TeamCity を使用しています。TeamCity を使用すると、CI サーバー部分のセットアップが簡単になり、nant ビルド スクリプトを使用すると、レポート生成に関する多くのタスクを簡単に実行できます。

以下は、CruiseControl.NET での CI の使用について書いた記事です。コメントには、プロジェクト間で再利用できる nant ビルド スクリプトがあります。

CruiseControl との継続的な統合

于 2008-08-27T12:22:15.957 に答える
1

buildbotを使用し、ビルドを個別のステップに分割します。ビルドステップを十分な粒度で分割することと、完全なユニットにすることの間には、バランスが必要です。

たとえば、私の現在のポジションでは、各プラットフォーム (Mac、Linux、Windows) のサブピースをそれぞれのプラットフォームで構築しています。次に、それらを最終的なディストリビューションになる最終バージョンにコンパイルする単一のステップ (いくつかのサブステップを含む) があります。

これらのステップのいずれかで問題が発生した場合、診断は非常に簡単です。

私のアドバイスは、ステップをできるだけ曖昧な言葉でホワイトボードに書き出し、それに基づいてステップを進めることです。私の場合、それは次のようになります。

  1. プラグインピースを構築する
    1. Mac 用にコンパイル
    2. PC用にコンパイル
    3. Linux 用にコンパイル
  2. 最終的なプラグインを作成する
  3. プラグイン テストを実行する
  4. 中間 IDE をビルドします (ビルドをブートストラップする必要があります)
  5. 最終的な IDE をビルドする
  6. IDE テストを実行する
于 2008-08-27T17:30:39.053 に答える
0

G'day、

統合テストについて話しているとき、私の大きな（明らかな）ヒントは、テストサーバーを可能な限り展開環境に近づけて構築および構成することです。

</thebloodyobvious> (-:

乾杯、ロブ

于 2008-08-27T12:43:03.443 に答える
0

私は間違いなく仕事を分解します。ビルドに変更を加える可能性が高く、1 つのモノリシック ビルドを検索するのではなく、タスクが小さい方が問題を追跡しやすくなります。

とにかく、小さなピースから 1 つの大きなジョブを作成できるはずです。

于 2008-08-27T12:24:20.600 に答える
0

タスクを個別の目標/操作に分割し、上位レベルのスクリプトを使用してそれらをすべて適切に結び付けます。

これにより、他の人がビルド プロセスを理解しやすくなり (チームの誰もが理解できるように、ドキュメントを作成しているのですよね?)、再利用の可能性も高まります。高レベルのスクリプトを再利用しない可能性がありますが (同様のプロジェクトがある場合は可能ですが)、個別の操作は (コピー/貼り付けであっても) かなり簡単に再利用できます。

リポジトリから最新のソースを取得する例を考えてみましょう。いくつかのログ ステートメントを使用してコードを取得するためのタスク/操作をグループ化し、適切なアカウント情報を参照する必要があります。これは、プロジェクト間で非常に簡単に再利用できるものです。

私のチームの環境では、開発マシン (スクリプトを作成/デバッグする場所) と CI サーバー (クリーンな環境で同じスクリプトを実行するだけなので) の間で共通のスクリプト環境を提供するため、NAnt を使用します。私たちは Jenkins を使用してビルドを管理していますが、その核心では、各プロジェクトは同じ NAnt スクリプトを呼び出すだけであり、結果を操作します (つまり、ビルド出力をアーカイブし、失敗したテストにフラグを立てるなど)。

于 2012-07-11T15:38:34.360 に答える