What CI/CD actually is
CI builds and tests every push on a clean machine so integration breaks surface in minutes. CD keeps that artifact always releasable: continuous delivery ships on a button, continuous deployment auto-ships every green commit.
Two developers spend a sprint apart. One refactors the auth module, the other adds a feature that calls it. Both “work on my machine.” On Friday they merge for the release and nothing builds — the function signature changed, a config key was renamed, and a test that never ran on a shared machine has been red for days. They lose the afternoon to integration archaeology. CI exists to make that Friday impossible: every push is built and tested automatically, on a clean machine, so the conflict surfaces in minutes on Tuesday instead of in panic on Friday.
CI: every push, built and tested on a clean machine
Continuous Integration is the practice of merging everyone’s work into a shared mainline frequently — ideally many times a day — and having an automated system build and test each integration the moment it lands. The key word is automated. A human running tests “when they remember” is not CI; a server that builds and tests every single push, with no exceptions, is.
The mechanism is a loop. You push a commit. A fresh, clean machine checks out exactly that commit, installs dependencies from scratch, compiles or bundles the code, and runs the test suite. Minutes later you get a verdict: green (integrated cleanly) or red (something broke). Because it runs on a clean machine with no leftover state from your laptop, it is the cure for “works on my machine” — if it builds and passes there, it builds and passes for everyone, because there is the neutral ground the artifact actually has to live in.
When you see a CI pipeline go red on a commit you pushed five minutes ago, that is the entire point: the pain is cheap now, localized, and fixable while the change is still in your head.
Why bother? Three reasons, all about catching problems while they are cheap. Early detection: a break found seconds after the commit that caused it is trivial to fix — you know exactly what changed. The same break found two weeks later, buried under fifty other commits, is an investigation. Small batches: integrating little and often means each merge carries little risk; the big-bang merge that ruins a Friday is replaced by dozens of boring, instant merges. Fast feedback: the developer who broke something learns within minutes, while the change is still loaded in their head, instead of after they have moved on to three other tasks.
CD: delivery vs deployment (two different D’s)
CI tells you the code is good. CD is about what happens next — getting that good code toward users. The trap for juniors is that “CD” means two related-but-distinct things, and teams use the letters loosely.
Continuous Delivery means every change that passes CI produces an artifact that is always releasable, and shipping it to production is a deliberate human decision — a button. The pipeline does all the work (build, test, package, maybe stage), and stops at a manual approval gate. You could release any green commit at any moment; you choose when.
Continuous Deployment removes that button: every commit that passes the full pipeline is automatically deployed to production, no human in the loop. It is continuous delivery plus the courage (and the test coverage, and the monitoring, and the ability to roll back fast) to let the machine ship on green.
The distinction matters because it is a maturity and risk choice, not a tooling one. Most teams run continuous delivery — always-releasable, ship on a button — long before they trust continuous deployment. Both rest on the same foundation: a pipeline you trust enough that “green” genuinely means “safe.”
▸Why this works
A useful mental model: CI answers “did this change integrate without breaking anything?” Continuous Delivery answers “is this change ready to release whenever we want?” Continuous Deployment answers “should we just release it ourselves, automatically?” Same pipeline, three increasing levels of trust — and you earn each level with tests, observability, and fast rollback, not by flipping a config flag.
The vocabulary the rest of this track assumes
Every tool you will meet — GitHub Actions, GitLab CI/CD, CircleCI, Jenkins — is a different dialect of the same handful of nouns. Learn them once here and the YAML in the next unit reads like prose:
| Term | What it means |
|---|---|
| Pipeline | The whole automated sequence triggered by an event (a push, a PR), from checkout to deploy. |
| Stage | A named phase of the pipeline (e.g. build, test, deploy) that runs after the previous one succeeds. |
| Job | A unit of work inside a stage (e.g. “run unit tests”). Jobs in a stage often run in parallel. |
| Runner | The machine (a clean VM or container) that actually executes a job’s steps. |
| Artifact | A file the pipeline produces and keeps — a built binary, a Docker image, a test report — to pass to a later stage or to deploy. |
| Gate | A checkpoint that must pass before the pipeline continues — all tests green, a required review, a manual approval. |
| Environment | A deploy target with its own config and secrets — staging, production — that an environment-scoped deploy job ships to. |
Together, these seven terms describe the complete lifecycle of a single change: it enters the pipeline, passes through stages composed of jobs, is built by a runner, produces an artifact, clears gates, and lands in an environment. Miss any link — say, a gate that never fires — and the pipeline has a blind spot.
These tools are a map, not a maze: GitHub Actions (workflows of jobs, runs on GitHub-hosted runners), GitLab CI/CD (stages and jobs in .gitlab-ci.yml), CircleCI, and the venerable Jenkins all express the same loop. Pick one and the rest are reskins.
The cultural half: trunk-based and a green main
CI is half tooling, half discipline, and the discipline is the part juniors underestimate. The point of integrating “continuously” is defeated if everyone works on a long-lived branch for two weeks and merges at the end — that just moves the painful Friday merge to a different Friday. The practice that makes CI real is trunk-based development: short-lived branches (hours to a day or two), merged into the mainline (main) frequently, behind small pull requests.
And the unbreakable rule: keep main green. The mainline must always be in a buildable, test-passing state, because that is what everyone else branches from and what continuous delivery is poised to ship at any moment. A red main blocks the whole team — nobody can trust their own build because the foundation is broken. When the pipeline goes red, fixing it (or reverting the offending commit) is the team’s top priority, ahead of new work. That social contract — small batches, fast merges, a mainline you can always trust — is what turns a pile of YAML into actual continuous integration.
A team ships to production only after a human clicks 'Release' in the pipeline, but every green commit is one click away from going live. Which practice is this?
A small team wants to start getting value from CI/CD this week. What is the highest-leverage first move?
- 01In one breath, what does CI actually do, and why does it cure 'works on my machine'?
- 02What is the difference between continuous delivery and continuous deployment, and why does it matter?
CI/CD is the automated spine of modern delivery. Continuous Integration builds and tests every push on a clean machine the instant it lands, so integration breaks surface in minutes rather than at a panicked release — it cures “works on my machine” because the clean machine is neutral ground, and it pays off through small batches, early detection, and fast feedback. CD comes in two flavours that juniors must keep apart: continuous delivery keeps every change always releasable and ships on a deliberate human button, while continuous deployment removes the button and auto-ships every green commit — the same pipeline, one more rung of trust earned with tests, monitoring, and rollback. Underneath sits a shared vocabulary — pipeline, stage, job, runner, artifact, gate, environment — that GitHub Actions, GitLab CI/CD, CircleCI, and Jenkins all just reskin. And none of the tooling matters without the culture: trunk-based development with short-lived branches, small frequent merges, and an unbreakable rule that main stays green so the whole team can trust the foundation they build and ship from. Now when you see a pipeline badge turn red on main, you know exactly what it means: everything stops until it is fixed, because a broken foundation poisons every branch built on top of it.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.