The terms in this document are defined according to how they're used in Cloud Deploy.
The software you are going to deploy using Cloud Deploy.
Delivery of the assets necessary to deploy an application into an intended target environment. In Cloud Deploy, application delivery consists of generating, promoting, and delivering your application's Kubernetes manifests into the cluster.
The container images to be deployed (build artifacts), and configuration files, such as manifests and Skaffold configs, that are used for the deployment (target artifacts).
Automation lets you configure your delivery pipeline and targets so that some actions can be performed on releases and rollouts for that pipeline, without requiring human intervention. For example, you can set up your delivery pipeline so that promotion into a specific target happens automatically, under the right circumstances. Learn more.
The behavior of an automation is defined in part by the automation rule. An automation rule defines what is automated, for example, promoting a release.
The available automation rules are listed in the document Using automation rules.
An instance of an Automation.
A deployment strategy in which you roll out your changes to a subset of users first, test it to ensure reliability, then roll it out fully.
See also, Controller rollout.
For Parallel deployment, a target that represents one of the multiple GKE, GKE Enterprise, or Cloud Run individual targets you're deploying to simultaneously.
A software engineering practice in which changes can be released to users safely, frequently, and mostly automatically.
A software engineering practice that results in changes to code and configuration being deployed automatically.
Whereas continuous delivery requires manual approval at one or more stages, continuous deployment is automatic, with no manual approval required.
Configuration for a system, such as a Kubernetes cluster, that describes the intended state and relies on that system to achieve that state. Contrast with imperative configuration, in which you describe the specific steps to achieve that state.
Besides rendering and deploying declarative Kubernetes manifests,
Cloud Deploy uses declarative resource definitions to define the
rendering and delivery process.
typical filenames for the Skaffold definition and delivery-pipeline definition.
A representation of the workflow that delivers an application to each target in a deployment progression.
Documentation for Cloud Deploy uses the term "delivery pipeline" to distinguish it from other pipelines you might use, such as a CI pipeline.
In Cloud Deploy, the delivery pipeline is defined in a YAML
clouddeploy.yaml—and that definition
consists of the following:
- Deployment targets
- The promotion sequence among those targets
See also Pipeline instance.
Placeholders that can be added to a manifest but that are not resolved as part of rendering. Instead, values for these placeholders are assigned after each target-specific manifest is rendered. Learn more.
A technique for safely deploying changes to your application while minimizing impact to users.
A set of Google Cloud resources on which Cloud Deploy runs. It consists of the following:
The default or private worker pool in which Cloud Deploy executes rendering and deploying actions
The default or alternate execution environment service account that calls Cloud Deploy to perform rendering and deploying
The default or alternate storage location for rendered manifests in Cloud Storage.
A specific operation to be performed on a rollout, such as deploy or verify. Learn more.
A child resource of a rollout, the job run is an instance of a job. That is, it represents an attempt to perform a job such as deploy or verify. Learn more.
A Kubernetes configuration object that is used to create, modify, and delete Kubernetes resources such as pods, deployments, services, or ingresses.
Manifests in Cloud Deploy exist in one of two states: rendered or
unrendered. An unrendered manifest is not ready for deployment into a target.
The rendering process, which includes populating specific values into the
manifest, is often performed by tools like Helm, Kustomize, and kpt.
Cloud Deploy uses Skaffold to orchestrate the rendering of
See also, Render.
When configuring or performing a parallel deployment, a multi-target is a single pipeline stage, but can comprise more than one target runtime.
The practice of deploying an application to more than one target at the same time, in the same delivery pipeline stage. This technique allows you to deploy to multiple clusters or services in production, for example.
The collection of operations (jobs) in a rollout that are logically grouped together, for example a deploy or a deploy and verify. Learn more.
A snapshot of a delivery pipeline, taken when a
release is created.
Cloud Deploy keeps this snapshot to ensure that all deployments of a
release are consistently managed using the pipeline as it was defined when the
See Pipeline instances per release for more information.
When a delivery pipeline or target is changed after a release is created, the
pipeline instance associated with the
release is now
different from the pipeline definition.
If there's a pipeline mismatch, Cloud Deploy prompts you to examine the definitions before you promote a release or attempt a rollback.
See Pipeline instances per release for more information.
A configuration, in your delivery pipeline configuration file, that describes a
promotion sequence from one target to another—for example from
The process of advancing a release from one target to another, according to the progression defined in the delivery pipeline.
To provide an application to the Cloud Deploy service, in the form of a delivery pipeline, so that the application's delivery is managed by the service.
A Cloud Deploy resource that represents the changes (code, configuration or both) to be deployed.
The release lifecycle is described in the document Cloud Deploy service architecture.
To prepare a manifest for deployment in the target. Rendering a manifest
consists mainly of providing values for the variables in the manifest.
Cloud Deploy does this using
This doesn't include populating values for deploy parameters
A resource that associates a release with a deployment
rollout is created per release per target, so in a simple
progression across three targets in a delivery pipeline, there would be three
rollout resources for the release—one for each target.
For more complex deployments, for example using a canary deployment strategy,
rollout can be more complicated. Learn more.
Standard deployment strategy
The standard deployment strategy is the default way of deploying an application to a target. For each stage defined in the delivery pipeline, your application is deployed fully to the target, each time replacing the application as it was previously deployed.
One target or multi-target in a delivery pipeline. For example, in a simple delivery pipeline that has the following stages:
Each of those is one stage.
Suspend (a delivery pipeline)
To prevent creation and promotion of releases from a given delivery pipeline. For more information, see Suspending a delivery pipeline
The specific runtime environment (Kubernetes cluster, Cloud Run service, or other supported runtime) into which to deploy the application. Also, the configuration for that environment.
You can define your targets in your delivery pipeline configuration file, or in a separate file.
A configuration file used for rendering and deploying an application on a target. These include Kubernetes manifest or Cloud Run service definition, Skaffold configuration files, and the rendering source used to create these.
The ability to confirm that a deployment was successful, by running an arbitrary container, with tests. Learn more about deployment verification.