1 つのアプローチは、Locks and Latchesプラグインを使用して、各パイプラインの各ジョブに独自のロック (例: Pipeline-A と Pipeline-B) を与えることです。その後、テストを実行するジョブは、Pipeline-A と Pipeline-A の両方でロックを取得するように構成されます。パイプライン-B。これにより、いずれかのパイプラインの一部が実行されている場合にテスト ジョブが実行されなくなり、テストの実行中にパイプラインの変更がブロックされます。
デプロイ ジョブのみをロックしたい場合は、同じアプローチを使用できますが、ロックを使用してデプロイ ジョブのみを構成できます。これにより、通常のビルドは通常どおり実行できますが、テストの実行中に展開ジョブがキューに入れられます。
仮定;
- Deploy ジョブがテスト実行をトリガーしている
2 つ目の方法は、デプロイを実行する前に、次のレイアウトで単一のジョブをトリガーするように、ジョブ パイプラインをセットアップすることです。
EndOfPipelineA -> SystemDeploymentController
EndOfPipelineB -> SystemDeploymentController
SystemDeploymentController -> DeployAppOne
SystemDeploymentController -> DeployAppTwo
DeployAppTwo -> TestExecution
DeployAppOne -> TestExecution
次に、Joinプラグインを使用して、両方のデプロイが完了し、成功した場合にのみ TestExecution ジョブを実行します。
2 番目のアプローチでは、次のことが可能になります。
- デプロイの成功に応じて、条件付きでテストの実行を制御します。
- システムが実行されているシステムに変更を加えた場合にシステム全体を再デプロイし、テストを自動的に実行できる単一のジョブを用意します。
- プロモーション プラグインを使用して、両方のアプリがうまく連携した「適切な構成」を強調する可能性があります
ただし、管理が少し面倒です。