3

私たちの環境では、現在、ビルド エージェントを拘束し、他のビルドを強制的にキューに入れる、かなりの数の長期実行機能テストがあります。これらのエージェントはテスト結果を待っているだけなので、理論的にはテストを他のマシン (テスト エージェント) に渡し、テスト結果が利用可能になるまでキューに入れられたビルドを実行することができます。

CI ビルド (単体テストを含む) の場合、失敗に関する即時のフィードバックが必要なため、これはインラインのままにしておく必要がありますが、機能テストの実行にかかる時間、結果のリード タイム、およびテストのスループットの間でより良いバランスを得ることができれば素晴らしいことです。私たちの集合的なビルド。

私が知る限り、TeamCity はこのシナリオをネイティブにサポートしていないため、いくつかのオプションがあると考えています。

  • さらにエージェントをスピンアップし、それらを「テスト」プールに割り当てます。これらのエージェントで実行する機能ビルド構成をトリガーします (成功した Ci ビルドによってトリガーされます)。これは最もクリーンな方法のように見えますが、ライセンスを購入するリード タイムがあり、必要なテスト エージェントの数が一時的に 2 倍 (またはそれ以上) になる別の環境でテストを実行する必要があるため、あまりうまく拡張できません。
  • ビルドまたはビルド ステップを追加して、外部マシンでテストを起動し、すぐにビルドを成功としてマークして、キューに入れられたビルドを処理できるようにします。テストが完了したら、ビルドを成功/失敗としてマークします。これは、以前のビルド (おそらく REST API?) の結果を更新できることに依存しています。何かを成功としてマークし、後で失敗として更新するのも見苦しく感じますが、監視対象を常に選択できるため、最終結果のみが表示されます。
  • ビルドのキューがなくなるまで、エージェントを起動し続けます。これに関する問題は、それが移動するターゲットであることです。プラトーがどこにあるか (またはプラトーが存在するかどうか) がわかっている場合は、これを使用できますが、使用パターンからすると、これは実行可能ではありません。

誰かが同様のシナリオで成功したか、または私が考えていなかった上記の長所/短所を知っていますか?

4

2 に答える 2

1

利用可能なオプションの説明はかなり正確なようです。ビルドの進行状況のライブ更新が必要な場合は、実行中のビルドごとに 1 つの TeamCity エージェントが「ビジー」である必要があります。

ここでの唯一の欠点は、エージェント ライセンスのコストのようです。テスト ビルドが他のマシンでプロセスを起動するだけの場合、TeamCity エージェント プロセス自体はローエンドのマシンで実行でき、1 台のコンピューターで多くのエージェントを実行することもできます。

2 番目のシナリオの拡張は、1 つのビルド構成ではなく 2 つのビルド構成にすることができます。1 つは外部プロセスを開始し、もう 1 つは外部プロセスの完了時にトリガーされ、すべての外部プロセスの結果を独自のものとして公開できます。関係を維持するために、開始ビルドにスナップショットの依存関係を持つこともできます。

于 2012-06-19T12:57:16.033 に答える
1

好奇心旺盛な方のために説明すると、最終的にエージェントをさらに購入し、テスト プールに割り当てることになりました。調査の結果、ビルド結果を更新できないことが判明しました (この醜さがすぐにサポートされない理由はよくわかります)。

于 2012-11-05T04:47:24.233 に答える