Building and implementing CI/CD pipelines · Topic 1 of 4
Designing CI/CD Pipelines for Apps, Infrastructure and ML
Design CI/CD pipelines on Google Cloud for apps, infrastructure and ML: Artifact Registry, hybrid targets, Cloud Build triggers and approval flows.
- 5 min
- Same pattern for apps, infrastructure and ML: build, test, store, deploy, verify.
- Build once and promote the same digest; use immutable tags.
- Triggers: branch, tag, pull request, manual, Pub/Sub, webhook, scheduled.
What it is
Designing a pipeline means deciding its stages, what starts it, what it produces, where it deploys and who must approve each step. The same ideas apply whether the payload is an application image, a Terraform change or a machine learning model.
A good design builds once, tests automatically at every stage, and moves the same artifact forward until it reaches production.
How it works
CI/CD of applications and infrastructure
| Payload | CI stage | CD stage |
|---|---|---|
| Application | Unit tests, build image, scan, push to Artifact Registry | Cloud Deploy release to GKE or Cloud Run targets |
| Infrastructure | terraform fmt, validate, plan on pull request, policy check | apply after merge, via Infrastructure Manager or a build step |
| Kubernetes config | Render and validate manifests | Config Sync or Argo CD pulls from Git |
| ML model | Data and training pipeline, model evaluation | Register the model, deploy to an endpoint with a traffic split |
For ML, Vertex AI Pipelines runs the training workflow, the Vertex AI Model Registry versions models, and a Vertex AI endpoint can split traffic between the current and new model. Cloud Build can start the pipeline when training code changes.
Continuous testing means tests at every stage: unit tests in CI, integration and load tests in staging, and verification checks after each production rollout.
Artifact management with Artifact Registry
- Build once, promote the digest. Staging and production run the identical image.
- Tag meaningfully with the commit SHA or version, and turn on immutable tags so a tag cannot be repointed.
- Separate repositories for snapshots and releases, or per team, with IAM per repository.
- Cleanup policies delete old untagged versions to control storage cost.
- Remote repositories cache public sources; virtual repositories give one URL over several.
Language packages (Maven, npm, Python) belong in Artifact Registry too, so builds do not depend on public mirrors.
Deployment to hybrid and multi-cloud environments
| Target | How |
|---|---|
| GKE clusters in any region | Cloud Deploy GKE targets |
| Clusters outside Google Cloud | Register them in a fleet as GKE attached clusters; deploy through Cloud Deploy or GitOps |
| Many clusters at once | Cloud Deploy multi-targets, or Config Sync across a fleet |
| Private networks | Cloud Build private pools reach private endpoints; Cloud Deploy can run its render and deploy jobs in a private pool |
GitOps tools such as Argo CD or Config Sync suit hybrid estates because each cluster pulls from Git, so the pipeline does not need inbound access to every cluster.
CI/CD pipeline triggers
| Trigger | Starts on |
|---|---|
| Push to branch | Commits matching a branch pattern, such as ^main$ |
| Tag | A tag matching a pattern, such as a release version |
| Pull request | A PR opened or updated, for pre-merge checks |
| Manual | A person or script runs it |
| Pub/Sub | A message, such as a new image pushed to Artifact Registry |
| Webhook | An HTTP call from an external system |
| Schedule | Cloud Scheduler calling a manual trigger, for nightly builds |
gcloud builds triggers create github --name=web-main --region=europe-west1 \
--repository=projects/acme-ci/locations/europe-west1/connections/gh/repositories/web \
--branch-pattern='^main$' --build-config=cloudbuild.yaml \
--service-account=projects/acme-ci/serviceAccounts/build-sa@acme-ci.iam.gserviceaccount.comUse included and ignored file filters in a monorepo so a change to one service does not rebuild all of them.
Configuring deployment processes and approvals
| Mechanism | Where | Effect |
|---|---|---|
requireApproval: true | Cloud Deploy target | Rollouts to that target wait for an approver |
| Cloud Deploy Approver role | IAM | Who may approve or reject rollouts |
| Build approval on a trigger | Cloud Build | A build waits for approval before it runs |
| Automatic promotion | Cloud Deploy automation | Promote to the next target after a successful rollout and wait time |
| Deploy policies | Cloud Deploy | Block rollouts to a target in a time window, such as a freeze |
Notifications from Cloud Deploy go to Pub/Sub, so an approval request can reach chat or a ticketing tool.
A worked example
A team wants every merge to reach staging automatically and production only after sign-off. A Cloud Build trigger on main builds, tests and pushes the image, then creates a Cloud Deploy release.
The staging rollout runs integration tests as verification, and an automation rule promotes successful staging rollouts to production. The production target requires approval, and only the release managers group has the Approver role.
How the exam asks about this
- "Production deployments must be signed off by the release manager, while staging is automatic." Set
requireApprovalon the production target and grant the Approver role to that group. - "A monorepo rebuilds every service on any commit." Add included file filters to each service's trigger.
- "A new model must receive 10% of prediction requests before full rollout." Deploy it to the same Vertex AI endpoint with a traffic split.
What to remember for the exam
- Same pattern for apps, infrastructure and ML: build, test, store, deploy, verify.
- Build once and promote the same digest; use immutable tags.
- Triggers: branch, tag, pull request, manual, Pub/Sub, webhook, scheduled.
- Approvals live on the Cloud Deploy target; approvers are set with IAM.
- Hybrid targets: attached clusters, private pools, or GitOps pulling from Git.
Running terraform apply without a saved plan recomputes the changes at apply time, which may differ from what was reviewed. Save the plan in the pipeline and apply that reviewed plan file.
Common mistakes
Approving by convention, not by control. A chat message saying "approved" stops nothing. Use requireApproval and IAM so the pipeline enforces it.
Separate pipelines that rebuild per environment. Different builds can differ. Promote one artifact through all targets.
Opening inbound access to on-premises clusters for CI. Pull-based GitOps or a registered fleet avoids exposing every cluster.
Check yourself
How do you make Cloud Deploy wait for sign-off before production?
Set requireApproval to true on the production target and grant the Cloud Deploy Approver role only to the people who may approve.
Why deploy by digest rather than by tag?
A digest identifies exact image content, so the image that passed tests is the one that runs, while a mutable tag can be repointed.
Which trigger type suits a nightly build?
A manual trigger invoked on a schedule by Cloud Scheduler.
Topic 1 of 4 in Building and implementing CI/CD pipelines
Test yourself on Building and implementing CI/CD pipelines
The full Google Cloud Professional Cloud DevOps Engineer question bank has 751 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.