Pipeline instances per release

When you invoke Cloud Deploy to create a new release to be managed by your delivery pipeline, the pipeline and targets are preserved in their current state for that release. You can still edit your delivery pipeline and target definition files, but the changes that you make affect future releases only.

Note: In addition to storing the pipeline instance with the release, Cloud Deploy also stores the execution environment, as defined with the target.

Why does Cloud Deploy do this?

To keep your releases reliable and durable, the delivery pipeline and its associated resources are preserved at the time the release is created. This preservation prevents recent changes to the delivery pipeline definition from affecting the release in ways the generated manifests might not be able to accommodate.

Why does this matter?

When a delivery pipeline is changed after your release is created, Cloud Deploy delivers the release according to the previous pipeline definition (as it was when the release was created) not the new definition. This behavior isn't a problem unless you, or someone else in your organization, expects the release to follow the updated pipeline behavior.

When does this matter?

• When you promote a release

  When the release was first created, Cloud Deploy took a snapshot of the pipeline. That snapshot—the pipeline instance—is the version of the pipeline that controls the deployment cycle of that release.

  If anyone does edit the pipeline, and then you promote the release to the next target, Cloud Deploy displays a warning informing you that the deployment might not behave as you expect. You can respond by confirming the promotion or canceling it.

  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

If you confirm that you want to continue, then the release is promoted to the intended target cluster, with that target configured as defined when you created the release. That is, changes to the target do not affect that release.

• When you approve a rollout

  As with promotion, if you approve a rollout and there's a mismatch between the pipeline instance associated with the release, and the current pipeline definition, Cloud Deploy displays a message telling you about the mismatch. You can confirm or cancel the approval.

• When you roll back a release.

  If a delivery pipeline or target is changed after a rollout, and you try to roll back, there will be a pipeline mismatch. Cloud Deploy will prompt you to confirm you really want to roll back. In this case, we strongly recommend you examine the change to the delivery pipeline or target before rolling back.