The basic words first, then the service.

Build, release, and deploy

Writing software has several steps. First, developers write code. Next, the code is built, which means turned into a runnable package, often a container image. Finally, the package is deployed, which means installed and started in a place where it runs, such as a Kubernetes cluster or a Cloud Run service.

CI and CD

• Continuous Integration (CI) is the habit of merging code often and automatically building and testing it. In Google Cloud, Cloud Build is a common CI tool.
• Continuous Delivery (CD) is the habit of automatically carrying tested software through environments toward production, with checks and approvals along the way. Cloud Deploy is Google Cloud’s CD service.

Environments

Most teams use more than one place to run software: a development environment for quick experiments, a test or staging environment that looks like the real thing, and a production environment used by real customers. Moving software from one to the next is called promotion.

So what is Cloud Deploy?

Cloud Deploy is a fully managed continuous delivery service. You describe your path, for example “dev, then staging, then production”, and Cloud Deploy takes each new version through that path, handling approvals, rollouts, checks, and rollbacks. It works with Google Kubernetes Engine (GKE) and Cloud Run, and with other targets through custom options.

The pain it removes.

The old way: scripts and hope

Many teams deploy with a pile of custom scripts, sometimes run by hand from a laptop. Each team writes its own scripts. Nobody is sure which version runs where. Approvals are done by chat messages. When something breaks at night, finding the previous good version is a scramble.

What goes wrong

• Inconsistency: staging and production are deployed in slightly different ways, so something that worked in staging fails in production.
• No clear record: who deployed what, when, and who approved it?
• Risky releases: new versions go to every user at once, so a bug hurts everyone.
• Slow recovery: rolling back is manual and stressful.
• Heavy maintenance: someone must build and maintain the deployment tool itself.

The Cloud Deploy answer

Cloud Deploy gives every team the same, repeatable path, with built-in approvals, history, safe rollout strategies, and fast rollbacks. Google runs the service, so you do not maintain a deployment tool.

The vocabulary of Cloud Deploy.

Delivery pipeline

A delivery pipeline is the path your software follows. It lists the stages in order, for example “dev, staging, production”. One pipeline usually belongs to one application or service.

Target

A target is a place where software runs, such as a GKE cluster or a Cloud Run service in a specific project and region. Each stage in a pipeline points to a target.

Stage

A stage is one step in the pipeline, linked to a target and optional settings. For example, the “staging” stage deploys to the staging cluster.

Release

A release is a specific version of your application that you want to deliver. It captures the exact container images and configuration files to deploy. Think of it as a sealed, labeled package. Once created, a release does not change, which makes deployments repeatable.

Rollout

A rollout is the act of deploying a release to one target. A release can have several rollouts, one for each stage it passes through.

Skaffold

Skaffold is an open-source tool that Cloud Deploy uses behind the scenes. It does two jobs: render your configuration into final deployable files, and deploy them to the target. A Skaffold configuration file in your project describes how.

Promotion and approval

Promotion moves a release to the next stage. An approval is a human decision, or sometimes an automatic one, that must happen before a rollout can begin on a protected target such as production.

How the pieces fit together.

The main pieces

• Source repository: where your code and deployment configuration live, such as a Git repository.
• Cloud Build or another CI tool: builds container images and creates a Cloud Deploy release.
• Artifact Registry: stores the container images that releases reference.
• Cloud Deploy service: holds pipelines, targets, releases, and rollouts, and orchestrates everything.
• Skaffold and execution environment: Cloud Deploy runs rendering and deployment work in a managed, temporary environment, using a service account you control.
• Targets: GKE clusters, Cloud Run services, or custom targets.
• Notifications and audit logs: Pub/Sub messages and Cloud Audit Logs describe what happened.

flowchart LR
  DEV["Developer pushes code"] --> GIT["Source repository"]
  GIT --> CB["Cloud Build: build and test"]
  CB --> AR["Artifact Registry: container image"]
  CB --> REL["Cloud Deploy: create release"]
  AR --> REL
  REL --> P["Delivery pipeline"]
  P --> T1["Dev target"]
  P --> T2["Staging target"]
  P --> T3["Production target"]
    

Where it runs

A pipeline and its targets belong to a Google Cloud region. Targets can live in different projects, which is useful when production is kept separate from development for security. Make sure the right permissions exist between projects.

The story of one release from creation to production.

sequenceDiagram
  participant CI as Cloud Build
  participant CD as Cloud Deploy
  participant D as Dev target
  participant S as Staging target
  participant A as Approver
  participant P as Production target
  CI->>CD: Create release with image and config
  CD->>D: Rollout to dev
  D-->>CD: Rollout succeeded
  CD->>S: Promote and rollout to staging
  S-->>CD: Verification passed
  CD->>A: Request approval for production
  A-->>CD: Approved
  CD->>P: Rollout to production
  P-->>CD: Rollout succeeded
    

Why the release is immutable

Because a release is a fixed snapshot, the exact same package is deployed to every stage. This avoids the classic problem of “it worked in staging, but production got a slightly different build”. The only differences between stages are the settings you intentionally change, such as the number of replicas or the database address.

The places Cloud Deploy can deliver to.

Same pipeline, different settings

Each stage can use a profile, a named set of overrides. For example, “dev” uses one copy of the app with small memory, while “production” uses ten copies with much more memory. The release is the same, but the final rendered configuration is tuned for each target.

Multi-target deployments

A single stage can point to a multi-target, which is a group of targets such as clusters in several regions. Cloud Deploy can roll out to all of them in parallel, which is useful for serving users worldwide.

flowchart TD
  R["Release"] --> S1["Stage 1: Dev profile"]
  S1 --> T1["Dev GKE cluster"]
  R --> S2["Stage 2: Staging profile"]
  S2 --> T2["Staging Cloud Run service"]
  R --> S3["Stage 3: Production profile"]
  S3 --> MT["Multi-target: production"]
  MT --> TA["Cluster in Asia"]
  MT --> TB["Cluster in Europe"]
  MT --> TC["Cluster in Americas"]
    

How a new version replaces the old one.

Standard deployment

In a standard strategy, the new version replaces the old one fully in one go. It is simple and fine for development and test environments, or low-risk services. The downside is that a bug reaches all users at once.

Canary deployment

A canary strategy sends the new version to a small share of traffic first, for example five percent. If all looks healthy, the share grows in steps, such as twenty-five percent, fifty percent, and finally one hundred percent. If problems appear, the rollout can stop and roll back, so only a few users are affected.

Parallel deployment

A parallel strategy deploys to multiple targets at the same time, such as many clusters, and tracks them together.

Blue-green thinking

Some teams also use a blue-green style, where a full new copy runs next to the old one and traffic is switched at once. Support depends on the target type and setup, so check the current documentation.

flowchart LR
  A["Start: 100 percent old version"] --> B["Step 1: 10 percent new"]
  B --> C{"Healthy?"}
  C -- "Yes" --> D["Step 2: 50 percent new"]
  D --> E{"Healthy?"}
  E -- "Yes" --> F["Step 3: 100 percent new"]
  C -- "No" --> R["Roll back to old version"]
  E -- "No" --> R
    

Making the pipeline smart.

Verification

Verification runs a test after a rollout to confirm that the new version works. You provide a container that runs checks, such as calling the service’s health endpoint or running a short set of end-to-end tests. If verification fails, the rollout is marked failed, which prevents bad versions from moving on.

Deploy hooks

A deploy hook is a custom action that runs before or after a deployment. A pre-deploy hook might run a database migration. A post-deploy hook might warm a cache or send a message. Hooks run in containers, so they can do almost anything you can script.

Automations

Automations are rules that reduce manual work. Examples in plain words:

• Automatically promote a release to staging as soon as the dev rollout succeeds.
• Automatically advance a canary rollout to the next step after a waiting time.
• Automatically retry or roll back a rollout that failed.
• Promote to production on a schedule, such as during a quiet maintenance window.

Approvals

A target can be marked as requiring approval. Cloud Deploy then pauses before any rollout to that target, and only people with the approver role can allow it to continue. This creates a clear record of who approved what and when.

When something goes wrong, go back fast.

What is a rollback?

A rollback returns a target to a previous good release. In Cloud Deploy, because earlier releases are saved snapshots, rolling back means redeploying a known release to that target. There is no need to rebuild anything.

When to roll back

• Error rates or response times rise after a rollout.
• A key feature is broken.
• A security issue is discovered in the new version.
• Verification or monitoring alerts fire.

Roll back or roll forward?

Sometimes it is faster to fix the bug and push a new release, called rolling forward. Choose based on the size of the problem and how sure you are of the fix. A rollback is usually the safer first move for serious production issues.

Database changes need care

Code can be rolled back easily, but data changes cannot always be undone. If a new version changes the database structure, an old version may no longer work with it. Use backward-compatible changes, such as adding columns first and removing old ones later, so rollback remains safe.

Deployment tools have powerful keys. Protect them.

IAM roles for people

IAM roles decide who can create pipelines and targets, create releases, promote them, and approve production rollouts. Separate these duties: developers may create releases and promote to dev and staging, while only a small group of approvers can approve production. This is the principle of separation of duties.

Service accounts for execution

Cloud Deploy runs work using a service account, an identity for programs. This account needs permission to deploy to the target and to read images from Artifact Registry. Give each target or pipeline its own tightly scoped account rather than one all-powerful account.

Supply chain security

• Trusted images: only deploy images from your own registry, built by your own pipeline.
• Vulnerability scanning: scan images in Artifact Registry and block releases with serious known problems.
• Binary Authorization: require that images be signed and attested as approved before they can run on GKE or Cloud Run.
• Build provenance: record how and where each image was built, so you can prove its origin.

Secrets and configuration

Never place passwords or keys inside release files. Use Secret Manager and reference secrets at run time.

Audit trail

Audit logs record who created releases, who approved rollouts, and who changed pipelines. These records support reviews and compliance checks.

Knowing what is running and how well your delivery process works.

Seeing the state of delivery

The Cloud Deploy console shows each pipeline with its stages, which release is running in each target, and the status of recent rollouts. You can click into a release to see its details, the exact rendered files, and logs from each step. A release inspector helps you compare what changed between releases.

Notifications

Cloud Deploy publishes messages to Pub/Sub when releases, rollouts, and approvals change state. You can connect these to chat tools, email, or ticketing systems. For example, send a message to the approvers when production is waiting for a decision.

Logs

Rendering and deployment steps write logs that are stored in Cloud Logging and Cloud Storage. Audit logs show administrative activity. When a rollout fails, these logs are the first place to look.

Delivery metrics

Cloud Deploy provides delivery metrics that help you measure how well your delivery process works. Teams often track the well-known DORA metrics:

• Deployment frequency: how often you ship.
• Lead time for changes: how long from code change to production.
• Change failure rate: how often releases cause problems.
• Time to restore service: how fast you recover from a failure.

Watch the application, too

Cloud Deploy knows whether a rollout succeeded, but only your monitoring knows whether users are happy. Use Cloud Monitoring and logging to watch error rates, delay, and traffic during and after rollouts, and connect alerts to your rollback process.

How it scales and what it costs.

Scale

Cloud Deploy is a managed service and is designed for many pipelines, targets, and releases. Large organizations create separate pipelines for each microservice and use multi-targets for global rollouts. Check the current quotas, such as the number of pipelines, targets, and concurrent rollouts, before designing a very large setup.

Speed of delivery

• Keep images small so pulls are fast.
• Use parallel deployment to reach many targets at once.
• Automate safe promotions so releases do not wait for people unnecessarily.
• Keep verification fast but meaningful.

What drives cost

• The Cloud Deploy service: pricing is typically based on active delivery pipelines or similar usage, with a free allowance that has existed in some form. Check the current price page.
• Build and execution time: Cloud Build and the managed environments that render and deploy.
• Storage: images in Artifact Registry and logs and artifacts in Cloud Storage.
• The environments themselves: clusters and services in dev, staging, and production, which are usually the largest cost.

Ways to save

• Shut down or scale down non-production environments outside working hours.
• Clean up old images and old release artifacts.
• Do not create many unused pipelines.
• Use small, shared staging environments where it makes sense.

An honest report card.

Compared with neighbors

Patterns that work, and traps to avoid.

Good patterns

flowchart TD
  C["Commit to main branch"] --> B["Cloud Build: test and build image"]
  B --> S["Scan and sign image"]
  S --> R["Create Cloud Deploy release"]
  R --> D["Auto-deploy to dev"]
  D --> V1["Verify in dev"]
  V1 --> ST["Auto-promote to staging"]
  ST --> V2["Verify in staging"]
  V2 --> AP["Manual approval"]
  AP --> PR["Canary rollout to production"]
  PR --> M["Monitor and roll back if needed"]
    

Anti-patterns

Your checklist, the usual stumbles, and where Cloud Deploy shines.

Best practices

• Start with one service and a simple three-stage pipeline.
• Define pipelines and targets as code and keep them in source control.
• Build once, promote the same release through every stage.
• Use profiles to change settings per environment, not different builds.
• Require approval for production and limit who can approve.
• Add verification after each rollout.
• Use canary rollouts for important production services.
• Send notifications to the right people when approval or failure occurs.
• Practice rollbacks regularly so the team is confident.
• Track delivery metrics and improve them over time.

Common mistakes

Real-world uses

You started with a toy factory that checked each product at several stations before it reached the shelves. You now understand that Cloud Deploy does the same for software: it moves each release through your environments with checks, approvals, and the ability to go back.