Google Cloud provides managed services for each stage of a delivery pipeline: building code, storing the results, releasing to environments and watching how the service behaves in production. This article walks through four of them using Google’s own documentation, and what each one is for.
Cloud Build: build and test
Cloud Build runs builds on Google Cloud infrastructure. It can import source code from a variety of repositories or Cloud Storage, run a build to your specification and produce artifacts such as Docker containers or Java archives. Builds are described in a YAML or JSON config file as a series of steps, and each step runs in its own Docker container. You can use builders published by Cloud Build, community builders, or your own.
- Triggers start builds automatically when code changes, and work with repositories such as GitHub and Bitbucket. Builds can also be started manually from the command line or the API.
- Deployment targets include GKE, Cloud Run, App Engine, Cloud Functions, Compute Engine and Firebase.
- Security features include build provenance for SLSA level 3 assurance, ephemeral build environments that are destroyed after each build, private pools with private network access, and customer-managed encryption keys.
Artifact Registry: store what you build
Artifact Registry is a single place to keep container images, Helm charts and language packages for Go, Java, Node.js, Python and Ruby, as well as OS packages such as Debian and RPM. Access is controlled with Google Cloud IAM, and container images can be scanned for vulnerabilities through Artifact Analysis.
It also supports remote repositories, which cache upstream dependencies so they can be scanned, and virtual repositories, which group remote and private repositories behind one endpoint. Repositories can be placed inside a VPC Service Controls perimeter for extra isolation.
Cloud Deploy: promote releases safely
Cloud Deploy is a managed service that delivers applications to a series of target environments in a defined promotion sequence. Targets include GKE, Cloud Run, GKE attached clusters and custom target types.
- A delivery pipeline defines the order of environments, for example test, staging and production.
- Approvals can be required before promoting to a given target, commonly production. Cloud Deploy publishes a Pub/Sub message so that a ticketing system can run the approval.
- Rollback redeploys the last successfully deployed release with its original parameters.
- Notifications are sent through Pub/Sub for render, deploy and approval events.
Cloud Monitoring: know whether it is working
Cloud Monitoring’s service monitoring is built around service level indicators (SLIs), service level objectives (SLOs) and error budgets. An SLI is a measurement of performance, such as the share of requests that succeed. An SLO is a target for that SLI over a period of time. The error budget is how far the service can fall short during that period and still meet the SLO. You can set up alerting policies that warn you when the error budget is being used up faster than you want, which gives earlier notice than waiting for the SLO itself to be breached.
How they fit together
Read in order, the four services cover a delivery path: Cloud Build produces the artifact, Artifact Registry holds it, Cloud Deploy moves it through environments with approvals, and Cloud Monitoring tells you how it behaves once it is live. You do not have to adopt all four. You can use the Google Cloud services that suit the parts of your estate running there alongside the tools you already have.
Where we can help
If you are building or reviewing pipelines on Google Cloud, or across several clouds, see our DevOps automation and engineering service, or get in touch.
Sources, checked October 2026: Google Cloud, Cloud Build overview; Google Cloud, Artifact Registry overview; Google Cloud, Cloud Deploy overview; Google Cloud, Cloud Monitoring service monitoring and SLOs.
