What's changed: Created Professional Cloud DevOps Engineer Chapter 2 (Domain 2 "CI/CD": Cloud Build (CI)/Cloud Deploy (CD; Skaffold/Kustomize)/Artifact Registry/triggers/approval flows; deployment strategies = canary/blue-green/rolling/traffic splitting/feature flags + telemetry success metrics; Cloud Audit Logs/Cloud KMS/Secret Manager/Workload Identity Federation; Artifact Analysis/Binary Authorization/SLSA/environment-based IAM).
2.1Designing CI/CD pipelines and deployment strategies
Understand continuous integration (CI) with Cloud Build, continuous delivery (CD) with Cloud Deploy (Skaffold/Kustomize), artifact management with Artifact Registry, deployment to hybrid/multi-cloud (GKE), pipeline triggers and approval flows, and deployment strategies (canary/blue-green/rolling/traffic splitting/feature flags) with success metrics.
CI/CD is the automated path that delivers code changes to production safely and repeatably. Chain build, test, artifact management, and deploy in a pipeline, releasing via low-risk deployment strategies.
2.1.1CI, CD, and artifact management
Continuous integration (CI) automates build and test with Cloud Build. Continuous delivery (CD) promotes staging→production progressively with Cloud Deploy, handling Kubernetes config via Skaffold/Kustomize. Store and version build artifacts (container images/packages) in Artifact Registry. Start pipelines via triggers (commit/tag/PR) and insert approval flows before production. Map "build/test = Cloud Build," "progressive deploy = Cloud Deploy," and "artifact store = Artifact Registry."
2.1.2Deployment strategies and success metrics
| Strategy | Key point |
|---|---|
| Canary | Release to a small slice first to catch issues early |
| Blue/green | Switch between two environments; instant rollback |
| Rolling | Replace instances gradually |
| Traffic splitting/feature flags | Split by percentage; toggle features dynamically |
Choose a strategy to release with less risk: canary (small slice first), blue/green (switch for instant rollback), rolling (gradual replacement), traffic splitting/feature flags (percentage split, dynamic toggles). After release, define success metrics from app/ML-pipeline telemetry and auto-rollback/halt on regression. Map "want instant rollback = blue/green" and "test on a slice = canary."
Common: requirement → means. E.g., "automate build/test" = Cloud Build; "progressive promote staging→prod" = Cloud Deploy; "store/version container images" = Artifact Registry; "validate with some users first" = canary; "instant fallback" = blue/green; "toggle features dynamically" = feature flags; "human approval before prod" = approval flows.
Watch the mix-ups: (1) Do not confuse Cloud Build (CI = build/test) with Cloud Deploy (CD = progressive deploy). (2) Canary (release to a slice) vs blue/green (switch whole environments) differ. (3) Judge deploy success by telemetry-based success metrics, not opinion.
2.1.3Section summary
- CI = Cloud Build, CD = Cloud Deploy (Skaffold/Kustomize), artifacts = Artifact Registry
- Start via triggers, gate prod with approval flows, choose a deployment strategy by requirement
- Canary/blue-green/rolling/traffic splitting/feature flags + telemetry-based success metrics
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To auto-run build and test on each commit, which is best?
Q2. To realize continuous delivery promoting staging→production progressively, which is best?
Q3. To store built container images with versioning and vulnerability-scan integration, which is best?
Q4. To release a new version to a small slice of traffic first and expand if healthy, which strategy?
Q5. To enable instant fallback to the previous version on problems, which deployment strategy is best?
Q6. To objectively decide whether a deploy succeeded, which criterion is best?