Cloud Deploy
Cloud Deploy is the managed continuous delivery service on Google Cloud. It is not CI — that is Cloud Build's role. It is the next step: taking an artifact that has already been built and promoting it through environments (dev to staging to production) with approval gates, canary rollouts, and automatic rollback. Targets are GKE clusters, Cloud Run services, GKE Enterprise clusters (formerly Anthos), and custom targets; the pipeline definition is YAML; the operational interface is the Google Cloud console plus gcloud.
The decision Cloud Deploy enables is "use a managed delivery pipeline instead of hand-rolled promotion scripts." The hand-rolled version usually starts as a bash script in CI that does kubectl apply against each environment in sequence; it grows into a mess of edge cases — what if dev passed but staging is broken, what about rollback, what about canary, what about approval. Cloud Deploy is the shape of that script written correctly once and managed thereafter.
Continuous Delivery Pipelines
A Cloud Deploy delivery pipeline is a YAML object that defines a sequence of stages. Each stage names a target (a GKE cluster, a Cloud Run service, a GKE Enterprise cluster) and a deployment strategy (standard, canary, custom). The pipeline lives in the project as a managed resource; releases flow through it.
A release is one specific artifact running through the pipeline. When Cloud Build finishes a build and triggers Cloud Deploy, a new release is created with the artifact's image reference. The release advances stage by stage — automatically where configured, or by manual promotion in the console — until it lands in production.
Targets and Stages
A target is a deployment destination. For GKE, a target is a specific cluster (plus optional namespace). For Cloud Run, a target is a Cloud Run service in a specific region. A stage pairs a target with a strategy: deploy the artifact to this target using this rollout pattern.
Common pipeline shape: dev target (auto-promoted), staging target (auto-promoted with smoke tests), production target (manual approval required). The stages encode the org's promotion process; new releases follow the same path through.
Promotion, Approval, and Rollback
Promotion moves a release from one stage to the next. Promotions can be automatic (the release advances as soon as the previous stage succeeds) or manual (a human clicks "promote" in the console after reviewing). The mix is typical: dev and staging are auto-promoted, prod requires manual approval.
Approval is the gate before a sensitive stage. The pipeline stops; a designated approver group sees the pending release in the console with build metadata, previous-stage results, and links to logs; one approver promotes. Audit logs record who approved.
Rollback reverts production to a previous release. Cloud Deploy retains the last several releases per target; rollback is a single command (gcloud deploy rollback) that redeploys the previous release without a new build. Without this, "we shipped a bad change, get us back to last week's version" turns into hours of digging through CI history and re-running builds.
Canary Deployments
A canary deployment routes a small percentage of traffic to the new version first, validates it under real production load, and only proceeds to full rollout if the canary is healthy. Cloud Deploy supports canary as a built-in strategy with configurable percentages (1%, 10%, 50%, 100%) and configurable verification — health checks, custom probes, or external SLO monitors.
The trap with canary deployments is treating "canary" as the strategy name and skipping the verification. A canary that ramps from 1% to 100% over an hour without any health signal is not actually a canary — it is a slow rollout with extra steps. Real canaries have measurable success criteria (error rate below X, p95 latency below Y, no spike in HTTP 5xx) and the pipeline aborts and rolls back if criteria are violated.
Cloud Deploy vs Self-Rolled Promotion
Cloud Deploy — managed pipeline, audit trail, approval gates, canary, rollback as built-in primitives. Operational surface is the console plus YAML. The right choice for production-grade delivery to GKE or Cloud Run.
Self-rolled promotion scripts — bash or Python in CI doing kubectl apply in sequence, with each operational concern (rollback, canary, approval) added over time as outages exposed the gap. Works in tiny teams; rarely scales without becoming a maintenance liability.
If the deployment target is GKE or Cloud Run and the pipeline has more than one environment to traverse, Cloud Deploy is almost always the right call.
- Custom promotion scripts maintained for years when Cloud Deploy would cover the case. Every team's bash-based deployer eventually rediscovers the need for the features Cloud Deploy ships natively.
- Direct push to production with no staging — no Cloud Deploy in the pipeline at all. Each release is a coin flip; rollback is improvised.
- No rollback plan in the pipeline. The team's assumption is "nothing will go wrong"; the first production incident reveals there is no documented or rehearsed rollback path.
- Approval gates skipped or auto-approved for production. The gate exists nominally; the human review does not.
- "Canary" deployment configured with no validation metrics — just a slow percentage ramp. The pipeline does not actually catch bad canaries because nothing is measuring them.
- IAM not scoped per stage. The same group that can promote to dev can promote to prod; the segregation that approval gates were supposed to provide is bypassed.
- Cloud Deploy for any production-grade deployment to GKE or Cloud Run with more than one environment. The hand-rolled alternative trades the YAML file for a much larger maintenance burden.
- Approval gates on transitions to production, especially for the first deploy after major schema or infrastructure changes.
- Automatic rollback on health check failure during canary. Define success criteria (error rate, latency, HTTP 5xx rate) explicitly; without them, "canary" is theater.
- Canary deployments with real validation metrics, not just percentage ramps. The pipeline must abort if criteria are violated.
- Separate IAM per stage. Dev promoters and prod promoters are different groups, even when the people overlap.
- Integration with Cloud Build at the trigger boundary — build produces image, image lands in Artifact Registry, Cloud Deploy starts a release. End-to-end automation with clear hand-offs.
Knowledge Check
What is the relationship between Cloud Build and Cloud Deploy?
- They are two marketing names for the same underlying service, applied at different stages of the pipeline but sharing one API, one console, and one billing meter
- Cloud Build is CI — it compiles and tests code, producing artifacts. Cloud Deploy is CD — it takes those artifacts and promotes them through environments to production.
- Cloud Deploy replaces Cloud Build entirely; the older Cloud Build service is being phased out in favor of a single unified Cloud Deploy pipeline that both builds and ships
- Cloud Build handles deployment to dev and staging environments, while Cloud Deploy is reserved strictly for the final promotion into production targets
Why does "canary deployment" without validation metrics not actually catch bad releases?
- Canary deployments are not a native Cloud Deploy feature at all; the gradual percentage ramp only ships as part of hand-written custom strategies, so without one defined in advance nothing actually happens during the rollout
- Without measurable success criteria (error rate, latency p95, HTTP 5xx rate), nothing actually evaluates the canary — the percentage ramp completes regardless of whether the new version is healthy
- Canary deployments work only on GKE targets; Cloud Run rollouts silently ignore the canary setting and always send all traffic to the new revision at once
- Validation metrics are a prerequisite for approval gates; when they are missing, the pipeline silently auto-skips every approval and promotes the release unattended
When does a self-rolled promotion script earn its place over Cloud Deploy?
- Always — a handful of bash scripts wired directly into CI are cheaper to write, run, and operate at any scale and for any team size, so a managed promotion service like Cloud Deploy simply never pays for itself no matter how large or complex the pipeline grows over time
- When the deployment target happens to be GKE, since Cloud Deploy only knows how to promote releases to Cloud Run and cannot drive a Kubernetes cluster on its own
- Rarely — tiny teams with one environment can get away with it, but as soon as the pipeline grows past one environment or needs rollback, canary, or approval gates, the self-rolled version becomes the maintenance liability that Cloud Deploy was designed to replace
- For all on-premises clusters, because Cloud Deploy is a cloud-only service that cannot reach GKE Enterprise targets and therefore leaves any data-center deployment to a hand-rolled script
What does gcloud deploy rollback do?
- Cancels an in-flight release that is still in the middle of being rolled out, aborting the promotion cleanly before any target environment has been touched or any production traffic shifted
- Redeploys a previous release to the target — no new build required — so "get us back to last week's version" is a single command instead of hours of CI history archaeology
- Reverts the underlying Artifact Registry repository, retagging it back to the previously stored image so the bad version is overwritten at the source
- Removes every pipeline configuration change made in the last 24 hours, reverting the delivery pipeline and target YAML to their prior committed state
Why scope IAM per stage in a Cloud Deploy pipeline?
- Cloud Deploy requires per-stage IAM bindings before approval gates can be configured at all; without a distinct role bound to each target in the pipeline the entire gate feature stays disabled and no promotion anywhere can ever pause to wait for a human sign-off
- When the same group can promote to dev and to prod, the approval gate's segregation-of-duties intent is bypassed — anyone who can sneak a release into dev can promote it forward; per-stage IAM keeps prod promoters a deliberately smaller, audited group
- Per-stage IAM is what unlocks cross-region deployment to multi-region GKE clusters, since each region's target reads its allowed footprint from the role bound to that pipeline stage
- Per-stage IAM is a prerequisite for rollback to function at all; without it, only the engineer who originally created the release retains permission to roll that release back later
You got correct