Skip to main content

Chapter 5 · CI/CD & GitOps

You can now build infrastructure as code (Chapter 3) and run containers on it (Chapter 4). This chapter answers the question that connects writing code to it actually running in production: how does a commit become a running service — automatically, repeatedly, and safely? That pipeline from change to production is the daily heartbeat of every software team, and getting it right is what lets you ship many times a day with confidence instead of dreading every release.

Why this chapter matters​

Manual deployment is slow, error-prone, and unrepeatable — the same problems IaC solved for infrastructure, now applied to shipping software. CI/CD (Continuous Integration / Continuous Delivery) automates the path from commit to production: every change is automatically built, tested, scanned, packaged, and rolled out through a defined series of gates. GitOps takes the declarative reconciliation idea from Terraform and Kubernetes and applies it to deployment itself — git becomes the single source of truth for what runs in production, and an agent inside the cluster continuously reconciles the live system to match. This is the same loop you met three times in Chapter 4, now governing releases.

The durable idea​

The deployment pipeline is a series of automated gates from commit to production; the artifact is built once and promoted unchanged; and the desired state of production lives in version control — not in someone's memory or a manual click.

Pipelines, immutable artifacts, declarative desired state, and reconciliation are durable. The specific CI tools, their YAML syntax, and the exact controller you run are dated and change constantly. Invest in the model; map the tools onto it.

Lessons in this chapter​

  • 5.1 — Pipelines: build → test → scan → artifact → deploy. The anatomy of a pipeline, the meaning of each stage, and the precise difference between Continuous Integration, Continuous Delivery, and Continuous Deployment.
  • 5.2 — Branching for CI: trunk-based development. Why long-lived feature branches break CI, what trunk-based development and short-lived branches buy you, and how merge queues keep a green main.
  • 5.3 — Artifacts, registries & supply-chain security. Immutable artifacts, semantic versioning, content-addressable digests vs mutable tags, registries, and the now-mandatory supply chain: SBOMs, signing, provenance, and SLSA levels.
  • 5.4 — Environments & promotion (build once, promote). Promoting one immutable artifact through dev → staging → prod via separate Git paths/overlays — not separate pipelines — with Kustomize/Helm doing the config templating.
  • 5.5 — GitOps: pull-based reconciliation with Argo CD & Flux. Git as the source of truth, declarative desired state, pull-based reconciliation inside the cluster, drift detection/correction, and why pull beats push (no cluster credentials in CI).
  • 5.6 — Progressive delivery & rollback. Blue-green, canary, and rolling deploys; feature flags; automated metric/SLO analysis with Argo Rollouts/Flagger; automatic abort; and why rollback is "revert the Git commit."
  • 5.7 — Pipeline security, OIDC & DORA feedback. Keyless cloud auth with OIDC federation, short-lived credentials, sealed/external secrets in Git, and wiring the DORA metrics back into the pipeline as a feedback loop.
  • 5.8 — Checkpoint. Quiz across the whole chapter.

Where this connects​

  • Back to Chapter 3 (IaC) — GitOps is the declarative, drift-eliminating model applied to deployment; pipelines often run terraform apply, and the same reconciliation loop governs both.
  • Back to Chapter 4 (Kubernetes) — GitOps controllers reconcile Kubernetes desired state; the artifact a pipeline ships is usually a container image referenced by an immutable digest.
  • Forward to Chapter 6 (Observability) — progressive delivery only works if you can measure whether a canary is healthy, which requires the metrics and SLOs of the next chapter; the DORA feedback loop closes here too.

Next: 5.1 Pipelines: build → test → scan → artifact → deploy →