いくつかのタイプのビルド構成を持つ TeamCity プロジェクトがあります。
- さまざまなアプリケーション コンポーネントを含み、バージョン管理のさまざまなサブツリーから構築されたアプリケーション パッケージ
- ロール パッケージ: アプリケーション パッケージをさまざまな構成で組み合わせます (アプリ サーバー ロールには共通コード + フロント エンドがあり、Web サービス ロールには共通コード + バックエンドなどがあります)。
- 回帰テスト、ロール パッケージを対応するテスト サーバーにデプロイし、長い Selenium テスト スイートを実行する一連のビルド手順
目標は、アプリケーション パッケージを頻繁にビルドして、単体テストが失敗したときにすぐにわかるようにすること、必要に応じてロール パッケージをビルドすること、およびテストする新しいロール パッケージがあるときにできるだけ頻繁に回帰テストを実行することです。しかし、リグレッション テストには時間がかかり、一度に 1 つのリグレッションしか実行できないため (テスト サーバーのセットを独占します)、実行開始時に常に最新の利用可能なパッケージを取得する必要があります。例えば：
3:00 コード チェックイン 3:01 アプリ パッケージのビルド (A1) 3:02 アプリ パッケージ A1 終了 3:02 ビルド ロール パッケージ (R1) 3:03 役割パッケージ R1 終了 3:04 R1 の回帰開始 3:10 コードをチェックイン 3:11 ビルド アプリ パッケージ (A2) 3:12 アプリ パッケージ A2 終了 3:12 ビルド ロール パッケージ (R2) 3:13 ロール パッケージ R2 終了 3:20 コードをチェックイン 3:21 ビルド アプリ パッケージ (A3) 3:22 アプリ パッケージ A3 終了 3:22 ビルド ロール パッケージ (R3) 3:23 ロール パッケージ R3 終了 R1 の 3:30 回帰終了 ** R2 では回帰は実行されません ** 3:30 R3 のリグレッション開始
これまでのところ、アーティファクトの依存関係とビルド トリガーを使用してこれを実装しました。
- アプリケーション パッケージはスケジュール トリガーによってトリガーされ、VCS トリガー ルールで関連するソース コードに制限されます。TeamCity の依存関係はありません。
- ロール パッケージは、関連するすべてのアプリケーション パッケージを指す Finish Build Triggers によってトリガーされます。それぞれに、関連するアプリケーション パッケージ (最後に成功したビルド) に対するアーティファクトの依存関係があります。
- 回帰テストは、すべてのロール パッケージを指す Finish Build Triggers によってトリガーされ、単一のエージェントでの実行に制限されます。すべてのロール パッケージにアーティファクトの依存関係があります。
これは、1 つのロールのみを再構築する場合には十分に機能します。ただし、複数の役割が同時に変更された場合、最初の役割が再構築されるとすぐに回帰テストの実行が開始され、そのテストが終了するまで残りの役割は取得されません。最後に変更されたロールが再構築されたときに、回帰の実行を開始したいと考えています。(注: エージェントよりも多くの役割があり、リグレッションはパッケージ ビルドとは別のエージェントで実行されます。)
スナップショットの依存関係は私が必要とするツールのように聞こえます...しかし、私の理解では、それらはすべての依存構成を同じ VCS リビジョンから強制的に実行するものであり、コードが変更されていない場合にパッケージを強制的に再構築することは避けたいと考えています。今日の唯一の変更がロール R にのみ影響するパッケージ内にある場合、ロール S/T/U は再構築されるべきではなく、それらの依存関係も再構築されるべきではありません。これは可能ですか？
編集: TeamCity 7.1.1 を実行しています。