Google Cloud services
20 / 24
Google Cloud

CI/CD — Cloud Build & Cloud Deploy

Build, test and release automatically, with a progression through environments that can be rolled back.

Cloud Build builds and tests. Cloud Deploy promotes the result through environments.

A kitchen that plates one dish and passes the identical plate down the line for tasting at each station, rather than cooking it again at every stop.

Key Concepts

1
    commit -> Cloud Build -> Artifact Registry -> Cloud Deploy
              build, test      the image          dev -> staging -> prod
2
Cloud Build runs steps as containers.
    steps:
      - name: gcr.io/cloud-builders/docker
        args: ['build', '-t', '$_IMAGE:$SHORT_SHA', '.']
      - name: gcr.io/cloud-builders/docker
        args: ['push', '$_IMAGE:$SHORT_SHA']
3
Every step is an image, so the build environment is whatever you need without installing anything on a runner.
4
It authenticates as a service account, so there are no cloud credentials to store — and that service account should be scoped tightly, because it can deploy.
5
Cloud Deploy owns the progression. A delivery pipeline defines ordered targets with approvals between them, and promotion moves the same artifact forward:
6
    dev      automatic on build
    staging  automatic, with verification
    prod     requires approval
7
Promoting the same artifact is the point. Rebuilding per environment means the thing you tested is not the thing you shipped.
8
Rollback is a first-class operation — Cloud Deploy redeploys the previous successful release rather than asking you to rebuild an old commit.
9
Cloud Run makes the release strategies easy, because traffic is a percentage on revisions:
10
    gcloud run deploy --no-traffic --tag=canary
    gcloud run services update-traffic --to-tags canary=5
    # watch metrics, then 50, then 100
11
Blue/green and canary are the same mechanism here: revisions plus a traffic split, with instant rollback by shifting traffic back.
12
Database migrations still break the neat picture, and saying so matters. Canary and rolling releases run two versions at once, so migrations must be backward compatible — add a column, deploy, backfill, remove the old one later. Never rename in one step.
13
Artifact Registry replaced Container Registry, and it holds language packages too, with vulnerability scanning on push.
14
What the interviewer is probing.1. "What does Cloud Deploy add over Cloud Build?" Probing: the separation. Stalls: "Nothing, it deploys." Moves up: it owns progression through ordered targets with approvals, promoting the same artifact rather than rebuilding, and rollback redeploys the previous release.
15
2. "Why promote the same artifact rather than rebuild?" Probing: the testing argument. Stalls: "It is faster." Moves up: rebuilding per environment means the thing you tested is not the thing you shipped.
16
3. "How does a Cloud Build step get its tools?" Probing: the container model. Stalls: "They are installed on the runner." Moves up: every step is a container image, so the build environment is whatever the step needs with nothing installed globally.
17
4. "What accumulates cost in Artifact Registry?" Probing: the housekeeping. Stalls: "Nothing." Moves up: untagged images build up and bill indefinitely unless cleanup policies are set.
Use cases:cloud-buildcloud-deployartifact-registrycanaryrollback