Revision · CI/CD

This part turned the release from a rare, terrifying event into an automated pipeline triggered by committing code. The throughline runs the length of it: at every step, what manual, error-prone step does this remove, and how does it make production safer?

What this part covered

• CI vs CD vs continuous deployment — three distinct ideas that differ in who decides when production updates; continuous delivery keeps a human gate, continuous deployment removes it, and small frequent releases keep the suspect singular when something breaks.
• Continuous integration — merge often to a shared trunk so drift never exceeds a day, build and test every push on a clean checkout, and “stop the line” on a red build; merge queues catch semantic conflicts between two green PRs.
• Pipelines and stages — an ordered Build → Test → Scan → Package → Deploy with gates between, ordered to fail as cheaply as possible, kept fast with caching and parallelism, and undermined by flaky tests that teach people to re-run red builds.
• Jenkins architecture — a Java automation server where the controller orchestrates and holds credentials while labelled agents execute steps; the controller should run no builds, and plugin sprawl is the top cause of fragility (see CVE-2024-23897).
• The Jenkinsfile — pipeline-as-code versioned in the repo, declarative or scripted, with ephemeral agents for clean builds, shared libraries for the blessed way to build, and a script-security sandbox because Groovy runs on the controller.
• Artifacts and registries — an artifact is immutable deployable bytes; a tag is a mutable pointer while a digest is a content hash, and the cardinal rule is build once and promote the same artifact, injecting only config per environment.
• Deployment strategies — rolling, blue-green, and canary each answer “how few users are exposed and how fast can you undo it?”; feature flags decouple deploy from release, and the mature posture is making a bad deploy cheap to undo (remember Knight Capital).
• GitOps — invert push-based deploys so an agent inside the cluster pulls declared state from Git; a deploy becomes a reviewed commit, rollback is git revert, and continuous reconciliation self-heals drift without CI holding prod credentials.
• Argo CD — a Kubernetes controller running that loop against a repo, configured via an Application (source, destination, sync policy) and reporting orthogonal sync and health status, with automated sync, self-heal, and prune.
• Jenkins to Argo CD — wiring push-CI to pull-CD across a trust boundary: Jenkins builds and pushes an image tagged with the git SHA and bumps a separate config repo, and Argo CD reconciles — so a leaked CI token can never reach the cluster.

The takeaway

Read end to end, the pipeline first builds trust in a change (prove it, then freeze it into a named artifact) and then gets that trusted artifact into production safely. The last pages reframe deployment itself as a reconciliation loop — the same control-loop idea from Kubernetes and IaC — so that by the end you can trace any commit to a user and name, at each step, what stops a bad change from getting through.