Google Cloud Build / Cloud Deploy (CI/CD)
by Google Cloud
Google Cloud’s managed CI/CD services for building, testing, and progressively delivering applications on GCP and hybrid environments.
See https://cloud.google.com/build and https://cloud.google.com/deploy
Overview
- Google Cloud Build (Cloud Build) is a managed CI service that builds, tests, and produces artifacts (containers, archives, etc.) on Google Cloud infrastructure. It executes builds as a series of containerized build steps and integrates with Artifact Registry, Cloud Storage and other GCP services.
- Google Cloud Deploy (Cloud Deploy) is a managed continuous delivery (CD) service for orchestrating progressive delivery (canary, blue/green, phased rollouts) to targets such as GKE, Anthos, and (where supported) Cloud Run. It consumes artifacts produced by build systems (commonly Cloud Build) and manages releases, rollouts, targets, and approvals.
Features
Cloud Build
- Declarative build config (cloudbuild.yaml / cloudbuild.json) with sequential or parallel build steps.
- First-class container build support and native publishing to Artifact Registry and Container Registry.
- Build Triggers for GitHub, GitLab, Cloud Source Repos, and Cloud Storage events.
- Prebuilt community steps and custom container steps; each step runs in a container.
- Private pools for VPC-accessible workers.
- Integration with Binary Authorization, Cloud KMS, and vulnerability scanning workflows.
- Logs and build history in Cloud Logging and Cloud Console; fine-grained IAM controls.
Cloud Deploy
- Delivery pipelines, targets, and releases model to define how artifacts progress from dev → staging → prod.
- Progressive delivery strategies: canary, traffic shifting, and phased rollouts with automated promotion or manual approvals.
- Targets documented as of 2026-10-05: GKE, Cloud Run and GKE attached clusters; canary strategies via GKE Service Networking, GKE Gateway API, Cloud Run or custom implementations; parallel deployment to multiple targets.
- Release tracking, rollback, and auditability with Cloud Console and APIs.
- Policy/approval gates and human approvals built into pipelines; deployment verification through analysis jobs (Google Cloud Observability or custom).
AI features
Neither the Cloud Build nor the Cloud Deploy overview page mentions AI features (checked 2026-10-05).
Claimed strengths (vendor positioning; opinion)
- Managed CI/CD on GCP: Cloud Build creates artifacts; Cloud Deploy orchestrates delivery.
- Progressive delivery primitives (rollouts, traffic splits, automated verification).
- Extensible: custom build steps, private worker pools, Binary Authorization and Artifact Registry integration.
- Opinion: a fit for teams using Kubernetes (GKE) and Cloud Run.
Pricing (summary)
Cloud Build
- Pricing is primarily per build-minute consumed, with a free tier per billing account; see the official pricing page for current allowances.
- Costs depend on machine type and region (see the pricing page).
- Additional charges may apply for Cloud Storage, Artifact Registry storage, Cloud Logging, and network egress.
- Official pricing: https://cloud.google.com/build/pricing
Cloud Deploy
- Cloud Deploy pricing model not verified. Consult:
- https://cloud.google.com/deploy/pricing (check current docs before budgeting)
Note: pricing and free-tier allowances change; always verify on the official product pricing pages before planning.
Typical workflow (practical example)
- Developer pushes code to GitHub/GitLab.
- Cloud Build trigger runs according to cloudbuild.yaml and builds a container image, runs tests, and pushes the image to Artifact Registry.
- Cloud Build (or a separate publisher job) creates a release reference/artifact metadata.
- Cloud Deploy picks the artifact and creates a release that targets staging; it runs automated verification steps (smoke-tests, metrics checks) and performs a canary rollout.
- After verification and/or manual approval, Cloud Deploy promotes the release to production, using traffic shifting to reduce risk.
Example cloudbuild.yaml (build + push image):
steps:
- name: gcr.io/cloud-builders/docker
args: ["build", "-t", "us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA", "."]
- name: gcr.io/cloud-builders/docker
args: ["push", "us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA"]
images:
- us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$SHORT_SHA High-level Cloud Deploy pipeline (conceptual):
- Define delivery pipeline with targets (dev, staging, prod).
- Configure deployment strategy per target (e.g., canary with X% initial traffic, verification checks, promotion schedule).
- Create releases that reference Artifact Registry image tags produced by Cloud Build.
Integrations
- Artifact Registry / Container Registry (artifact storage; Container Registry status not verified).
- Cloud Source Repositories, GitHub, GitLab (triggers and source control).
- Binary Authorization, KMS, Cloud IAM (security & access control).
- Cloud Monitoring / Cloud Logging (observability for verification policies).
- GKE / Anthos, Cloud Run (deployment targets).
- External CI/CD tools (Jenkins, GitHub Actions) can call Cloud Build APIs or push artifacts into Artifact Registry consumed by Cloud Deploy.
Best practices
- Keep cloudbuild.yaml under source control alongside application code for reproducible builds.
- Push immutable, tagged artifacts to Artifact Registry and reference tags/sha in Cloud Deploy releases.
- Use private pools if builds require access to private networks or credentials not routable from public workers.
- Integrate automated verification (smoke tests, health checks, SLO-based checks) into Cloud Deploy pipelines to enable safe automated promotions.
- Use Binary Authorization and signed images to enforce supply chain trust.
- Tag and label builds and releases for traceability between source commit → artifact → release → rollout.
Security considerations
- Use least-privilege IAM roles for build service accounts and deployer identities.
- Enable Binary Authorization and image vulnerability scanning where possible.
- Keep secrets out of build configs; use Secret Manager and inject secrets at build-time via approved mechanisms.
- Use private pools for sensitive builds that must access VPC-only resources.
When to choose Cloud Build + Cloud Deploy
- Opinion: fits if you want a GCP-native, managed CI/CD stack integrated with Artifact Registry and GKE/Anthos.
- Opinion: fits if you need progressive delivery patterns (canary, blue/green) with promotion and rollback.
- Opinion: fits if you prefer managed services to operating your own Jenkins/ArgoCD.
Useful links
- Cloud Build: https://cloud.google.com/build
- Cloud Build pricing: https://cloud.google.com/build/pricing
- Cloud Deploy: https://cloud.google.com/deploy
- Artifact Registry: https://cloud.google.com/artifact-registry
Related: Cloud Run, Anthos (superseded), Google Cloud.
Sources
Fetched 2026-10-05.
- Cloud Build overview: https://docs.cloud.google.com/build/docs/overview
- Cloud Deploy overview: https://docs.cloud.google.com/deploy/docs/overview
- Pricing: https://cloud.google.com/build/pricing , https://cloud.google.com/deploy/pricing
Open items
- Cloud Deploy pricing model and any Container Registry to Artifact Registry transition details not checked.
- Trigger source list was only partly verified (docs list GitHub, GitLab, Bitbucket variants, Cloud Source Repositories, webhooks and Pub/Sub).