Cloud Deploy is a managed service that automates delivery of yourapplications to a series oftargetenvironments in a defined promotion sequence. When you want to deploy yourupdated application, you create arelease,whoselifecycleis managed by adelivery pipeline.

How a Cloud Deploy pipeline works

The Cloud Deploy delivery pipeline contains the following information:

• A name, which you use when referring to the delivery pipeline, and adescription.

• The promotion sequence, describing the order in which to deploy to theconfiguredtargets.

• Optionally,labels and annotations.

• Also optionally, the target definitions themselves.

Targets can bedefined in thesame delivery pipelineconfiguration file, or inone or more separate files. Multiple delivery pipelines can use the sametarget or targets, but a given target can be used only once in a given deliverypipeline.

The Cloud Deploy delivery process

The following is a description of a Cloud Deploy continuous deliveryscenario.

1. You define yourdelivery pipelinein aYAML configuration file.

   This configuration file defines the promotion sequence in which to deployyour application to a series oftargets.

   You also need aconfiguration forSkaffold, which Cloud Deploy needs in order toperform render and deploy operations.

2. You define your targets, either in the pipeline configuration file or in aseparate file or files.

3. You register your pipeline with the Cloud Deploy service.

   Now that the service knows about your application, it manages the deploymentto targets according to your defined promotion sequence.

4. The output of your CI process includes a call to Cloud Deploy toinitiate your delivery pipeline.

   This call creates arelease resource, representing the rendered manifestfor each target, each of which is generated using the provided renderingsource, skaffold.yaml, and references to specific container images to deploy.For this first call to create arelease,Cloud Deploy automatically creates arolloutresource, which associates the release with the first target environment.Based on that rollout, your application is deployed to the first target.

   You can use any CI tool as long as it outputs one or more container images toprovide to your Cloud Deploy delivery pipeline.

   Furthermore, the call to create a release and invoke a delivery pipelinedoesn't have to come from the CI tool. It can come from a script or anysystem responding to the completion of the CI process.

5. When you're ready to deploy your application to the next target, you callCloud Deploy to promote it.

   In each case, the call to invoke the promotion causes Cloud Deployto create a new rollout.

6. Promotion continues through all targets in your promotion sequence, the lastof which isprod (or whatever name you use for your final target to put theapplication into production).

   The process of release creation and promotion is described in more detail inCloud Deploy service architecture.

Throughout pipeline execution, Cloud Deploy collects metrics andaudit details.

Promotion

Topromote a releaseis to deploy it to the next target in the promotion sequence defined in yourpipeline. The first call to Cloud Deploy creates arelease, then arollout resource that's used to deploy to the first target in the promotionsequence. Each subsequent call to promote the release results in a rollout tothe next target.

Approvals

You can specify that an approval is needed for promotion to any target. Forexample, you might want to require approval for promotion into a productiontarget. To require approval for a target, set therequireApproval property inthetarget definition.

When a target requires approval, Cloud Deploy generates aPub/Sub message that can be consumed by an integrated system.For example, a ticketing system could subscribe to the message to kick off anapproval workflow.

SeeRequire approval for moreinformation on promotions and managing approval for promotions.

Notifications

Cloud Deploy provides Pub/Sub notifications for the followingevents:

• Render: start, success, and failure
• Deploy: start, success, and failure
• Approval required
• Approval approved
• Approval rejected

Cloud Deploy uses a Pub/Sub topic to send thesenotifications.

SeeUsing Cloud Deploy notifications for more details.

Rollbacks

Cloud Deploy supports rolling back your deployed application in anytarget. A rollback in Cloud Deploy consists of triggering a rolloutagainst the last successfully deployed release. The new rollout uses the sameparameters that were used in that successful deployment.

SeeRolling back a deployment for more details.

About Skaffold and Cloud Deploy

Cloud Deploy usesSkaffold for rendering, deployment,and verification. With Skaffold, you can also connect your local developmentloop to a Cloud Deploy continuous delivery pipeline.

To learn more about how Cloud Deploy integrates with Skaffold, seetheSkaffold overview.

Cloud Deploy with other Google Cloud tools

Cloud Deploy supports almost any tool upstream in a CI/CD pipeline.That is, you can use any development environment and source code repository, anycontinuous integration (CI) system, and any artifact repository.

Downstream, Cloud Deploy deploys to Cloud Run andGoogle Kubernetes Engine, including GKE attached clusters.

If you used mostly Google Cloud tools, your source-to-prod flowwould look like this:

1. UseCloud Code to create your application source.

   Cloud Code extends several popular IDEs (VS Code, IntelliJ,Cloud Shell) to make it easier to build applications to deploy and run onGoogle Cloud.

2. UseSkaffold to manage your local development loop.

   Cloud Deploy uses Skaffold, through Cloud Build, torender and deploy your manifests. This integration means that you need tomaintain askaffold.yaml file, but does not otherwise mean you need to makeSkaffold part of your local development flow. But you can take advantage ofit forcontinuous development.

3. Build your application using Cloud Build.

   Cloud Build lets you set up a CI pipeline that can betriggered from a commit to your source code repository. The output fromCloud Build will be artifacts including deployable containerimages. You can add a call to Cloud Deploy to create a releaseand invoke your delivery pipeline.

4. Store your artifacts in Artifact Registry.

   Cloud Deploy retrieves the container image or images fromArtifact Registry, which lets you centrally storeartifacts and dependencies.

5. Configure your delivery pipeline in Cloud Deploy to take thecontainer image and deploy it in a progression ofn targets.

   Targets identified in your delivery pipeline representGKE clusters, Cloud Run services orjobs, or GKE attached clusters where your application is ultimatelydeployed.

6. Manage your application on GKE orCloud Run.

   GKE is theGoogle Cloud managed environment for running containerizedapplications on Kubernetes.

   WithCloud Run, you can run containers in aserverless environment.

   GKE attached clustersprovide a consistent development and operations experience for cloud andon-premises environments.

7. Monitor the performance of your application using Google Cloud Observability.

   Google Cloud Observability offers integrated monitoring andlogging for your application.

What's next

• For a quick-and-easy look at how to create a delivery pipeline and use it todeploy an application, try thequickstarts.

• Try out one of theCloud Deploy walkthroughs.

• Learn more abouthow Cloud Deploy components work together.

• ReviewGoogle Cloud Well-Architected Framework: Operational excellencefor articles on how to use the principles of operational excellence to build anautomated delivery foundation.

• Learn how to combine Google Cloud CI/CD tools to develop and deliversoftware effectively to GKE.