Cloud Deploy を起動し、デリバリー パイプラインで管理する新しいリリースを作成すると、パイプラインとターゲットはそのリリースの現在の状態に保持されます。デリバリー パイプラインとターゲット定義ファイルは引き続き編集できますが、行った変更は将来のリリースにのみ適用されます。
Cloud Deploy でこれを行う理由
リリースの信頼性と耐久性を維持するため、リリース時にデリバリー パイプラインと関連リソースが保持されます。この保持により、デリバリー パイプライン定義に対する最近の変更が、生成されたマニフェストが対応できない方法でリリースに影響することを防止できます。
なぜこれが重要なのか
リリースの作成後にデリバリー パイプラインを変更すると、Cloud Deploy は新しい定義ではなく、以前のパイプライン定義（リリース作成時の定義）に従ってリリースを配信します。リリースで更新されたパイプラインの動作が期待されている場合を除き、この動作は問題ありません。
これを行うタイミング
releaseを昇格させる場合リリースが最初に作成されたときに、Cloud Deploy はパイプラインのスナップショットを作成しました。このスナップショット（パイプライン インスタンス）は、その
releaseのデプロイ サイクルを制御するパイプラインのバージョンです。誰かがパイプラインを編集し、リリースを次のターゲットに昇格させると、Cloud Deploy は、デプロイが想定どおりに動作しない可能性があることを示す警告を表示します。昇格を確認するかキャンセルすることで、対応できます。
gcloud deploy releases promote… The pipeline or targets were cached when the release was created, but the source has changed since then. You should review the differences before proceeding. Promoting release xxxx-release-00n to target xxx. Do you want to continue (Y/n)?
続行することを確定した場合、リリースが目的のターゲット クラスタに昇格され、そのターゲットが release の作成時に定義されたように構成されます。つまり、ターゲットの変更は release に影響しません。
rolloutを承認する場合昇格と同様に、
rolloutを承認し、リリースに関連付けられたパイプライン インスタンスと現在のパイプライン定義の間に不一致がある場合、Cloud Deploy はその不一致を伝えるメッセージを表示します。承認を確定またはキャンセルできます。releaseをロールバックする場合。rolloutの後にデリバリー パイプラインまたはターゲットが変更され、ロールバックしようとすると、パイプラインの不一致が発生します。Cloud Deploy では、本当にロールバックするかどうかを確認するよう求められます。この場合、ロールバックする前にデリバリー パイプラインまたはターゲットへの変更を確認することを強くおすすめします。
対応策
リリースの作成後にデリバリー パイプラインまたはそのターゲットを変更する場合は、次のことができます。
編集したパイプラインの変更を加えずに、元のパイプラインの実行を続行します。
パイプラインの変更は、リリースの残りの部分には影響しません。
新しいリリースを作成します。
新しいリリースでは、編集された新しいデリバリー パイプラインが使用され、デリバリー パイプラインの進行の最初のターゲットから再び開始されます。