What CI/CD Actually Is

“CI/CD” is one of those phrases people say fluently and define vaguely. It is actually three ideas wearing one acronym, and the second C is doing double duty. Getting the definitions crisp is worth a few minutes, because each idea removes a different manual step and buys a different kind of safety.

Start from the problem. A change is born on a developer’s machine. Between there and a happy user sit a pile of chores: build it, test it, scan it, package it, ship it, watch it. Historically every chore was done by a person, on demand, differently each time. CI/CD is the practice of encoding those chores as an automated pipeline so they happen the same way, every time, triggered by code itself.

The three terms, precisely

   ┌─ Continuous Integration ─┐ ┌──── Continuous Delivery ─────┐
   │ on every push:            │ │ + auto-package a releasable  │
   │  • build                  │ │   artifact, deploy to staging│
   │  • run tests              │ │  PROD release = one          │
   │  • merge to trunk often   │ │  human button-press          │
   └───────────────────────────┘ └──────────────────────────────┘
                                  ┌─── Continuous Deployment ────┐
                                  │ same as Delivery, but PROD   │
                                  │ release is ALSO automatic —  │
                                  │ no human gate. Pass = ship.  │
                                  └──────────────────────────────┘

Continuous Integration (CI) is the discipline of merging every developer’s work into a shared mainline frequently — at least daily — and having an automated system build and test every change as it arrives. The “integration” is the point: code that lives unmerged on a branch for two weeks is two weeks of divergence waiting to explode at merge time. CI says: integrate constantly, and let a machine prove on each integration that the project still builds and passes its tests. (The next page is entirely about this.)

Continuous Delivery (CD) extends CI rightward. Now every change that passes is automatically packaged into a releasable artifact and deployed through your pre-production environments. The system is always in a deployable state — any green build could go to production at the push of a button. The key word is could: with Continuous Delivery, the final step to production is a deliberate human decision.

Continuous Deployment removes even that last human gate. If a change passes every automated check, it goes to production automatically — no one presses a button. This is the same as Continuous Delivery in every respect except the final approval, which is why the acronym is ambiguous: “CD” can mean either, and the distinction is exactly one button.

The one distinction that matters

Continuous Delivery = always ready to release; a human decides when. Continuous Deployment = always releasing; the pipeline decides, because the tests are trusted enough. Same pipeline, one difference: who (or what) approves the production step.

Why the manual baseline was so dangerous

Lay the manual world next to the automated one and the value is obvious.

Step	Manual release	CI/CD pipeline
Build	On someone’s laptop, ad hoc	Clean, reproducible, on every push
Test	”Did you run them?” “Mostly.”	Enforced gate; can’t be skipped
Package	Hand-copied tarball, untracked	Immutable, versioned artifact
Release	SSH in, restart, hope	Repeatable strategy with rollback
Frequency	Rare, batched, scary	Small, frequent, boring

Every row of the left column is a place a human forgets, improvises, or cuts a corner under deadline pressure — and because releases were rare, each one carried weeks of accumulated change, so when something broke, you had a haystack to search. This is the book’s thread in its purest form: CI/CD removes the manual, error-prone steps between code and production, and the safety comes from the steps being automated, identical every time, and impossible to skip. A test you can’t forget to run is a different kind of safety net than one you’re supposed to remember.

”Continuous” means small and frequent

There’s a subtle reason small-and-frequent is safer, and it’s worth internalizing now. When you ship a hundred tiny changes, each one is easy to reason about, and if production wobbles right after a deploy, the suspect is that one small change. When you ship one giant quarterly release, a failure could be hidden in any of a thousand changes. Automation is what makes small-and-frequent practical — no one would do a fifty-step manual release ten times a day, but a machine will do it ten thousand times without complaint. Speed and stability stop being a tradeoff; they start reinforcing each other.

A pipeline is not magic, and we’ll demystify it the same way we demystified containers: it’s a sequence of ordinary commands — build, test, push, deploy — that a server runs for you on a trigger. The rest of this Part walks each stage. But the mental model to carry forward is this picture: CI proves a change is good; CD gets that good change to users; “continuous” means it happens in a steady stream of small steps instead of rare, terrifying leaps.

By the numbers — what “continuous” looked like at Amazon

The small-and-frequent argument isn’t theoretical. As far back as 2011, Amazon reported deploying to production astonishingly often once the pipeline did the work:

mean time between deployments ≈ 11.6 seconds
max deployments in a single hour  = 1,079

No human runs a fifty-step release every 11.6 seconds — a machine does. Those figures are the thread made numeric: automate the manual steps and the batch size of each change collapses toward one, which is exactly what lets speed and stability reinforce each other instead of trade off.

The architect’s lens

Five questions for CI/CD as a practice — and for where on the spectrum to stop:

• Why does it exist? Because shipping by hand made releases rare, batched, and terrifying — CI/CD encodes the chores (build, test, scan, package, ship) as an automated pipeline that runs identically on every commit.
• What problem does it solve? The error-prone manual baseline: an enforced test gate can’t be skipped, an immutable artifact replaces a hand-copied tarball, and small frequent deploys make the suspect of any wobble that one change.
• What are the trade-offs? The Delivery-vs-Deployment line is exactly one button: Continuous Deployment ships on every green build, which demands tests trustworthy enough to release with no human — you either buy that trust or keep the manual gate.
• When should I avoid it? You don’t avoid CI; you choose where to stop — full Continuous Deployment is the wrong call when a regulated change or a weak test suite still warrants a human approval gate.
• What breaks if I remove it? Releases revert to an event — build on a laptop, “mostly” run the tests, SSH in and restart and hope — and weeks of batched change turn every failure into a haystack search.

Check your understanding

1. State the precise difference between Continuous Delivery and Continuous Deployment. Which “C” is ambiguous and why?
2. What does the “integration” in Continuous Integration actually refer to, and what problem does integrating frequently prevent?
3. Why is a test enforced as a pipeline gate a fundamentally different kind of safety net than a test a developer is “supposed to remember”?
4. Explain why small, frequent releases make debugging a production problem easier than large, batched ones.
5. Using the book’s thread, pick any one row of the manual-vs-pipeline table and explain the manual step it removes and the safety it buys.

Show answers

1. With Continuous Delivery every green build could go to prod but a human decides when; with Continuous Deployment a passing change goes to prod automatically, with no human gate. The second C is ambiguous because “CD” can mean either Delivery or Deployment — the only difference is who or what approves the production step.
2. It refers to merging every developer’s work into a shared mainline frequently, at least daily. Integrating constantly prevents merge hell — code that diverges on a branch for weeks and explodes into conflicts and broken assumptions when finally merged.
3. A gate can’t be skipped — when wired to branch protection, a red build literally blocks the merge. A test you’re “supposed to remember” depends on human memory under deadline pressure, which is exactly the error-prone step automation removes.
4. Each small change is easy to reason about, so when prod wobbles right after a deploy the suspect is that one change. A large batched release hides a failure among a thousand changes, turning debugging into a haystack search.
5. Example (Release row): the manual step is “SSH in, restart, hope” — improvised, easy to fumble. The pipeline replaces it with a repeatable deployment strategy that has built-in rollback, so a bad release is bounded and reversible instead of a scramble.