リリースあたりのパイプライン インスタンス数

Cloud Deploy を起動し、デリバリー パイプラインで管理する新しいリリースを作成すると、パイプラインとターゲットはそのリリースの現在の状態に保持されます。デリバリー パイプラインとターゲット定義ファイルは引き続き編集できますが、行った変更は将来のリリースにのみ適用されます。

Cloud Deploy でこれを行う理由

リリースの信頼性と耐久性を維持するため、リリース時にデリバリー パイプラインと関連リソースが保持されます。この保持により、デリバリー パイプライン定義に対する最近の変更が、生成されたマニフェストが対応できない方法でリリースに影響することを防止できます。

なぜこれが重要なのか

リリースの作成後にデリバリー パイプラインを変更すると、Cloud Deploy は新しい定義ではなく、以前のパイプライン定義(リリース作成時の定義)に従ってリリースを配信します。リリースで更新されたパイプラインの動作が期待されている場合を除き、この動作は問題ありません。

これを行うタイミング

  • release を昇格させる場合

    リリースが最初に作成されたときに、Cloud Deploy はパイプラインのスナップショットを作成しました。このスナップショット(パイプライン インスタンス)は、その release のデプロイ サイクルを制御するパイプラインのバージョンです。

    誰かがパイプラインを編集し、リリースを次のターゲットに昇格させると、Cloud Deploy は、デプロイが想定どおりに動作しない可能性があることを示す警告を表示します。昇格を確認するかキャンセルすることで、対応できます。

  gcloud deploy releases promote 
      …
      WARNING: The delivery pipeline was modified since  was created.
      This release will promote based on the state of the delivery pipeline at the
      time of release creation.
      It will not be rolled out to the pipeline in its current state.
      Promoting will result in .
      Learn more at: https://cloud.google.com/deploy/docs/pipeline-instances
      Are you sure you want to promote  to ? Y/n

続行することを確定した場合、リリースが目的のターゲット クラスタに昇格され、そのターゲットが release の作成時に定義されたように構成されます。つまり、ターゲットの変更は release には影響しません。

  • rollout を承認する場合

    昇格と同様に、rollout を承認し、リリースに関連付けられたパイプライン インスタンスと現在のパイプライン定義の間に不一致がある場合、Cloud Deploy はその不一致を伝えるメッセージを表示します。承認を確定またはキャンセルできます。

  • release をロールバックする場合。

    rollout の後にデリバリー パイプラインまたはターゲットが変更され、ロールバックしようとすると、パイプラインの不一致が発生します。Cloud Deploy では、本当にロールバックするかどうかを確認するよう求められます。この場合、ロールバックする前にデリバリー パイプラインまたはターゲットへの変更を確認することを強くおすすめします。