6

TeamCity 6 で一連のビルド構成を構成しようとしており、TeamCity によって可能になる最もクリーンな方法で特定の要件をモデル化しようとしています。

並行して実行したい一連の受け入れテスト (関連するシステムの機能領域ごとにグループ化された約 4 ～ 8 のテスト スイート) があります (それらをビルド構成としてモデル化して、複数のプラットフォームに分散できるようにします)。エージェントのセット)。

私の最初の調査から、スナップショットの依存関係AcceptanceTestsを介して個々の受け入れテスト構成のセットを取り込むメタビルド構成を持つことは、うまくいくはずです。次に、ビルド構成がトリガーされ、それらがすべて取り込まれると言うだけです。CommitAcceptanceTestsAcceptanceSuiteAAcceptanceSuiteBAcceptanceSuiteC

これまでのところ、とても良いです (別の方法で構成Commitをトリガーすることもできます。問題はAcceptanceSuiteA、結果AcceptanceSuiteBをAcceptanceSuiteC手動で集計して、受け入れテスト全体の全体的な成功を判断する必要があることです)。

複雑なのは、いくつかのアーティファクトAcceptanceSuiteCが必要なだけで、それ自体で生きることができ、次のことを行う必要があることです。CommitAcceptanceSuiteAAcceptanceSuiteB

  • DeploySite（2分かかるとしましょう。この実行のためだけに完全に分離されたものをスピンアップする余裕はありません）
  • デプロイされたサイトに対してテストを実行する

問題は、次のことを確認できる必要があることです。

  • ウェブサイトは一度だけ設定されます
  • 2 つのスイートの実行中に Web サイトが破壊されることはありません

DeploySiteビルド構成として設定し、それをスナップショットの依存関係として取得しAcceptanceSuiteAてAcceptanceSuiteBプルすると、AFAICT:

  • の後続の実行または並行実行により、AcceptanceSuiteB別の実行がトリガーされ、使用中のおよび/または使用中DeploySiteの展開が破壊される可能性があります。AcceptanceSuiteAAcceptanceSuiteB

同時に実行するビルドの数を制限して、一度に 1 つだけ実行するように強制することはできますが、依存部分がまだ実行されている間ではなく、一度に 1 つずつ実行する必要があります。

TeamCity でそのような階層をモデル化する方法はありますか?

編集: アイデア:-

がらくたの解決策はDeploySite、「使用中フラグ」マーカーを設定し、構成でそのフラグをAcceptanceTestsクリアすることです[完了後]。問題は、ゲートが再び開かれるまで、次のパイプラインを待機させることの 1 つになります (ビルド内でブロッキング待機を行うと、気分が悪くなります。何かをするのに長い時間がかかる）。ただし、この種のものはここにフラグがあり、このビットをチェックしてください。これは、私が逃げようとしている一種の可変状態/フレークネスの匂いです。AcceptanceSuiteAAcceptanceSuiteBDeploySite

編集 2: エージェントの構成をプログラムで変更できれば、Agent Requirementsを require InUse=falseに設定し、デプロイの開始時にフラグを設定し、テストの実行後にフラグをクリアできます。

4

1 に答える 1

3

最初にJetbrains DevnetとYouTrack トラッカーを調べて、検索で魔法の言葉を使用することを忘れないようclobberです。

次に、groovy-plugをインストールして機能を使用しStartBuildPreconditionます。

この機能を使用するには、system.locks.readLock を追加します。または system.locks.writeLock。プロパティをビルド構成に追加します。writeLock を使用したビルドは、同じ名前の読み取りまたは書き込みロックで実行されているビルドがない場合にのみ開始されます。readLock を使用したビルドは、同じ名前の書き込みロックを使用して実行されているビルドがない場合にのみ開始されます。

その中で、依存構成が「読み取り」、構成DeploySiteが共有アイテムを「書き込む」という事実を管理します。

(これは完全に製品化されたソリューションではないため、トラッカー アイテムは開いたままです)

編集:そして、ロックがビルドパラメーター|システムプロパティの下にある必要があるかどうか、および正確な名前の形式がどうあるべきかはまだわかりませんlocks.writeLock.MYLOCKNAME(つまり、参照構文で構成に表示されます%system.locks.writeLock.MYLOCKNAME%)?

他の難問は次のとおりです: writeLock タスクの読み取りアクセスのビルド完了によってトリガーされるビルドの提供をどのように管理するか - 次のロックが取得されるまでロックが解除されるか (別のライターが許可される) - または、何かをキューに入れる必要があるか親と子の依存関係を同時に？

于 2011-04-11T12:26:27.970 に答える