自動ビルドはすべて Team City で行われます。
私たちが取り組んでいる最も自動化されたプロジェクトは、事実上コンパイラです。私たちのテスト スイートは、チェックインごとに実行される、コンパイルおよび実行される約 20000 のテスト クエリで構成されています。以前はこれに 1 時間近くかかっていましたが、(毎回チェックアウトするのではなく) ビルド マシンの RAM ドライブに完全なテスト スイートを保持することで、これを数分に短縮できます。
毎晩、これらと同じテストを実行する 2 番目のビルドがトリガーされますが、コード カバレッジ レポートを生成する NCover の下で実行されている間、4 つの異なるプロファイルの下で実行されます。このシナリオには数時間かかるため、ナイトリー ビルドとして実行されます。すべてが正常に機能していることを確認するために、他の内部レポートも同時に作成されます。
テスト スイート自体の更新は個別にトリガーされ、次の実行に備えて RAM ドライブにチェックアウトされます。それ以外の場合は、テストのチェックアウトにビルド時間のほとんどが費やされていました。テスト スイートの一部は、リモートの CVS リポジトリから取得され、ビルド時間に数分追加された更新を照会することさえできません。したがって、これは「更新テスト」ビルドでも行われます。この疎結合により、このプロジェクトのビルドを 1 台のマシンに制限する必要がありましたが、フィードバックは非常に迅速であるため、これは大きな問題ではありません。
コードベースの高いカバレッジを維持しながら、「通常の」テスト ビルドをできるだけ高速に維持することが非常に役立つことが証明されています。遅いテスト (1 秒以上) はナイトリー ビルドにプルされています。私たちのケースでは、テストを RAM ドライブに保持することは本当に役に立ちましたが、私たちのシナリオはかなり専門的です。データベースをモックすることが最も近いと思います。私のアドバイスは、「分厚い」または遅いテストを削除して、1 つのビルドを「無駄のない」状態に保つことです。他のビルドは別のマシンで実行することも、高速ビルドからの応答を迅速に保つために夜間に実行することもできます。
概観すると、(別のプロジェクトの) 最も長い自動ビルドは 1 日以上かかることがありますが、ありがたいことに、定期的に実行する必要があるビルドではありません。