DEVOPS-01-003-P · Primer — Continuous Delivery & Deployment (CD)

The idea in one sentence

Continuous Delivery keeps every commit in a state where it could ship to production at the push of a button; Continuous Deployment removes the button and ships automatically once the pipeline is green.

Why it exists

Before CD, teams batched weeks of changes into a "release" — a tense, manual, all‑hands event where someone followed a wiki page of steps at 2 am and prayed. Think of it like a grocery store that only opens its checkout lanes once a day: a long line builds up, a single cashier must handle every item, and any mistake stalls the whole crowd. CD breaks that batch‑checkout model. By shipping tiny increments continuously, each release carries almost no risk, and when something does break you know exactly which commit caused it. The DORA research (Accelerate) found this empirically — elite teams deploy many times a day with lower change‑failure rates than teams that deploy monthly, because small and frequent is safer than large and rare.

How it works

A CD pipeline is an automated conveyor belt that a commit rides from merge to production. After CI proves the code compiles and unit tests pass, the pipeline builds one immutable artifact once (a container image, a versioned bundle) and promotes that same artifact through environments — staging, then production — running integration, acceptance, and smoke tests at each gate.

Worked example:

• A developer merges a PR at 09:00. The CI build starts and finishes in 5 minutes, producing version app‑v1.2.3‑sha1a2b3c.
• Unit and integration tests run for another 2 minutes and all pass, so the artifact is promoted to the staging environment.
• Staging runs a full suite of acceptance tests for 3 minutes; they succeed, and the pipeline automatically rolls the artifact out to a canary that receives 1 % of live traffic.
• The canary monitors golden signals for 10 minutes; error rate stays <0.1 % and latency is unchanged, so the rollout widens to 5 %.
• After another 5 minutes of healthy metrics the rollout expands to 25 %, then to 100 % at 09:30. If any stage had crossed a threshold, the pipeline would have rolled back to the previous stable version automatically.

With Continuous Delivery, the final promotion to production waits for a human click; with Continuous Deployment, a green pipeline promotes itself, no human in the loop. The safety net that makes auto‑promotion sane is progressive rollout: ship to 1 % of traffic (a canary), watch the golden signals, then widen to 5 %, 25 %, 100 % — and roll back automatically if error rate or latency degrades.

See it — a commit rides the pipeline from merge to 100%

flowchart LR
  A["Merge to main"] --> B["Build artifact<br/>once"]
  B --> C["Auto tests<br/>+ staging"]
  C --> D{"Delivery or<br/>Deployment?"}
  D -->|"manual click"| E["Delivery:<br/>human approves"]
  D -->|"auto, if green"| F["Deployment:<br/>no button"]
  E --> G["Canary 1% to<br/>100%"]
  F --> G

The one gotcha

The only place bugs can hide is outside the pipeline. Any manual step—whether a one‑off database migration, a hand‑edited config file, or an ad‑hoc script run over SSH—bypasses the automated safety net, making it untested, unreviewed, and impossible to reproduce. If a production issue stems from such a step, the pipeline gave you a false sense of security. The cure is simple: every operation that affects production must be codified, version‑controlled, and executed by the pipeline.

The one-line takeaway

If a release step is manual, that's where the bug hides.

Where you'll meet it

You'll build these pipelines in GitHub Actions, GitLab CI, Jenkins, or Argo; promote container images through a registry into Kubernetes; provision the environments with Terraform so staging and prod are identical; and watch canaries with Prometheus and Grafana, wiring automatic rollback to the golden signals. Argo Rollouts and Spinnaker exist specifically to run the canary‑and‑rollback dance. The name to know from the source is Humble and Farley's Continuous Delivery; the yardstick is DORA's deployment frequency and lead‑time‑for‑changes.

Named concepts: continuous delivery, continuous deployment, deployment pipeline