AWS CodePipelineの複数のビルドに対する手動承認の作業

Question

ビルドを実行し、QA ECS環境にデプロイし、次に手動承認手順を使用してProdにデプロイするCodePipelineが設定されています。

何が混乱するかは、いくつかのビルドが次々に実行されている場合です。いくつかのビルドがQAに順番に展開されますが、承認ボタンが一度に1つずつ承認されるようですが、クリックすると承認するビルドは不明です。

以前のビルドには、それ以降のビルドで修正された問題があった場合に、最新のビルドを承認することができます。それを達成するための最良の方法は何でしょうか？

Answer 1

展開と承認アクションを同じステージに配置する必要があります。これにより、テストしたものを正確に承認することができます。どうして？正確に1つのパイプライン実行は、パイプライン段階でいつでも実行できるためです。

...最新のビルドを承認します。以前のビルドには、それ以降のビルドで修正された の問題があった場合に備えてください。

後でビルドが追いつくようにしたい場合は、承認待ちの古いビルドを拒否します。

Answer 2

私は同じ問題を抱えていました。いくつかのパイプラインの実行がキューに入れられる可能性があるため、マニュアルの承認は混乱を招きます。私はこれをCodePipelineの悪いUXに責められると思う。

私が解決した回避策は、同じプロジェクトに対して2つの同一のパイプラインを使用することです。彼らは同じソース段階（同じレポ/ブランチ）を持っていますが、展開段階が異なります（1つはQAにデプロイ、1つはプロデュースに展開）。これ以上の手動承認の段階はありません。 Prodパイプラインを手動で解放する必要がある間に、ソース（レポ/ブランチ）の変更が検出されると、QAパイプラインは自動実行に設定されます。

基本的には、マニュアル承認をマニュアルリリースに置き換えました。マニュアルのリリースは、手動による承認とは異なり、常に最新のソースをリリースします。

Answer 3

複数のパイプラインを必要としない場合は、制御されたリリースが必要な環境へのステージ移行をデフォルトで無効にすることです。

環境に展開する準備ができたら、ステージ遷移を有効にして、前のステージからの最新のリリースを処理できるようにしてから、再びトランジションを無効にします。

これはまだちょっと大変ですが、使い慣れれば合理的に効果的です。あなたが行った各変更を拒否しなければならないのは非常に遅く、管理が面倒なので、移行を無効にすると、いつリリースを促進するのかが決まります。

IMOでは、手動承認段階で一時停止された場合、CodePipelineは自動的に実行に優先するオプションが必要です。