Part 5 · CI/CD

You can build the perfect container image and run it on a flawless Kubernetes cluster, and none of it ships a single line of code to a user. Something still has to take the change a developer just typed, prove it works, package it, and put it in front of customers — over and over, many times a day, without a human babysitting each step. That “something” is CI/CD, and it is the connective tissue of everything in this book.

Think about the alternative, because it is how software actually used to ship. A release was an event. Someone pulled the latest code, built it by hand on their laptop, ran whatever tests they remembered, copied a tarball to a server over SSH, restarted the service, and watched the logs with their fingers crossed. Every step was manual. Every step was a place to forget something, build on the wrong branch, or skip the test “just this once.” Releases were rare and terrifying precisely because they were manual — and rare, terrifying releases batch up huge amounts of change, which makes them even more dangerous. (That vicious circle is exactly the one Speed vs Stability and the DORA metrics were about.)

CI/CD breaks the circle by turning the release from an event into a pipeline: a fixed, automated sequence that runs the same way every time, triggered by the act of committing code. This Part is the recurring thread of the whole book made literal — what manual, error-prone step does this remove, and how does it make production safer? — because CI/CD is the machinery that removes those steps for a living.

The path from commit to production

Here is the whole journey on one page. Every box is a step a human used to do by hand.

   developer                    CI                          CD
   ─────────                    ──                          ──
   write code ──► git push ──► build ──► test ──► scan ──► package ──► deploy ──► prod
                    │            │        │        │          │           │
                    │           fail?    fail?    fail?    artifact    rollout
                    │            └────────┴────────┴──► stop the line   strategy
                    │                                  (never reaches prod)
                    └── trunk: merge small changes, often ──┘

Two halves, two jobs:

• CI (Continuous Integration) is the left side: every push is automatically built and tested, so broken code is caught within minutes of being written — not weeks later when someone tries to release.
• CD (Continuous Delivery / Deployment) is the right side: a change that passes is automatically packaged into an immutable artifact and rolled out to environments using a strategy that limits the blast radius and makes rollback fast.

One artifact, the whole way down

A theme you’ll see repeatedly: the same artifact that CI built and tested is the one promoted to staging and then production. Nothing is rebuilt per environment. “It passed in test” only means something if the bytes in production are identical to the bytes that were tested.

Roadmap for this Part

Read these in order — each builds on the last.

#	Page	What it answers
2	What CI/CD Actually Is	CI vs CD vs continuous deployment — the precise definitions
3	Continuous Integration	Why merging often + testing every push catches breakage early
4	Pipelines & Stages	Stages, gates, caching, parallelism — with a real workflow
4.1	Jenkins: Architecture	The controller/agent model of the classic self-hosted CI server
4.2	The Jenkinsfile	Pipeline-as-code in depth — declarative syntax, agents, the sandbox
5	Artifacts & Registries	Immutable, versioned artifacts and promoting the same one
6	Deployment Strategies	Rolling, blue-green, canary, flags — and fast rollback
7	GitOps	Git as the single source of truth for desired state
8	GitOps with Argo CD	A controller that reconciles a cluster to a git repo
8.1	Jenkins → Argo CD	Wiring push-CI to pull-CD across the trust boundary

Notice the shape of the journey. The first half (pages 2–5) is about building trust in a change: prove it works, then freeze it into an artifact you can name and trust. The second half (pages 6–8) is about getting that trusted artifact into production safely — and the last two pages reframe deployment itself as a reconciliation loop, the same control-loop idea that runs the rest of your infrastructure.

By the end you should be able to look at any commit and trace, with no hand-waving, exactly how it reaches a user — and explain at each step what stops a bad change from getting through.

Check your understanding

1. Why does treating a release as a manual event tend to make releases both rarer and more dangerous?
2. In one sentence each, what is the job of the CI half of the pipeline versus the CD half?
3. What does “promote the same artifact” mean, and why does rebuilding per environment undermine the value of testing?
4. Using the book’s recurring thread, name three manual steps from the old SSH-and-tarball release that a CI/CD pipeline removes.
5. The last two pages reframe deployment as a reconciliation loop. Why might “pull the desired state from git” be safer than “push changes to a server”?

Show answers

1. A manual event is rare because it’s slow and frightening, so changes pile up between releases — and a release that carries weeks of accumulated change is more likely to break and harder to debug. Rarity and danger reinforce each other, which is the vicious circle Speed vs Stability describes.
2. CI automatically builds and tests every push so broken code is caught within minutes of being written; CD automatically packages a passing change into an immutable artifact and rolls it out with a strategy that limits blast radius and keeps rollback fast.
3. It means the exact same bytes that CI built and tested are the ones promoted to staging and then prod — nothing is rebuilt per environment. Rebuilding per environment means “it passed in test” says nothing, because the bytes in production are no longer provably identical to the bytes that were tested.
4. Any three of: building by hand on a laptop, running whatever tests you remembered, copying a tarball over SSH, restarting the service manually, and watching logs by hand. The pipeline encodes each as an automated, identical, un-skippable step.
5. Pulling means an agent inside the cluster reconciles reality to a reviewed git declaration, so CI never holds prod credentials, drift is detected and corrected, and “what’s running” is always answerable from git — whereas a push is a one-shot action with no standing check that it stayed applied.