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

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

Google Cloud Deploy でこれを行う理由

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

これが重要なのはなぜでしょうか。

リリースの作成後にデリバリー パイプラインを変更すると、Google Cloud Deploy は新しい定義ではなく、以前のパイプライン定義(リリース作成時の定義)に従ってリリースを配信します。ご自身または組織内の別のユーザーが、更新されたパイプラインの動作に従うことが想定されない限り、この動作は問題になりません。

これを行うタイミング

  • release を昇格させる場合

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

    誰かがパイプラインを編集し、リリースを次のターゲットに昇格させると、Google 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 を承認し、リリースに関連付けられたパイプライン インスタンスと現在のパイプライン定義の間に不一致がある場合、Google Cloud Deploy はその不一致を伝えるメッセージを表示します。承認を確定またはキャンセルできます。

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

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