A CI/CD pipeline, stage by stage
One saved change walks the whole road from a developer's laptop to production — hooks, build, tests, scans, staging, approval, canary and the rollback that makes it all safe.
You save a change
A pipeline starts with something tiny: one person saving one change. At a company the size of Google that happens tens of thousands of times a day, and every single change has to survive the same gauntlet before a real user ever sees it.
A pre-commit hook checks the diff
Before the commit even exists, a hook runs on your own laptop. It formats the code and rejects the obvious mistakes in about a second. That is the cheapest place in the world to catch a problem: no server, no queue, nobody waiting.
The push wakes a clean runner
The push wakes a runner, usually a fresh container that has never seen your project before. Starting from a blank machine every time is the entire point. It proves the build does not secretly depend on something only your laptop happens to have installed.
Compile and package
Now the code is compiled and packaged. This is where a warm dependency cache earns its keep: restoring one can turn a nine minute build into a ninety second one, and teams watch that number the way athletes watch a lap time.
Unit tests run in parallel
Unit tests fire next, often thousands of them, spread across parallel workers so the clock stays short. Ten minutes is the informal limit. Past that, developers stop waiting for the result and start ignoring it, and a test suite nobody reads is worse than none.
All checks green?
Here is the gate, and it has no opinions. Every check either returns success or it does not. One failing assertion out of four thousand is enough to stop the entire release, which is exactly the discipline that makes the rest of this trustworthy.
A red build stops the line
A red build is not a disaster, it is the machine doing its job. The change never merges, the author hears within minutes, and the fix is cheap because the code is still warm in their head. Catch that same bug in production instead and it costs a rollback, an incident and a room full of people.
Static analysis and secret scan
Then the security pass. Static analysis reads the code for injection flaws, a secret scanner hunts for an access key somebody pasted by accident, and a dependency audit checks every library you pulled in against a public database of known vulnerabilities.
Signed artifact in the registry
What falls out is the artifact: one immutable, versioned, cryptographically signed bundle, parked in a registry. It is built exactly once. Every environment from here on deploys that identical package, so staging and production can never quietly drift apart.
Deploy to staging
Staging is production's understudy — same container, same shape of configuration, a smaller copy of the data. Its job is the class of failure that only appears when real infrastructure is involved: a missing environment variable, or a database migration that locks a table for a minute.
Smoke tests hit the running copy
Smoke tests now poke the running service from outside, the way a user would. Log in, load a page, place a test order. They are deliberately shallow and quick, perhaps twenty checks in under a minute, answering one blunt question: is this thing obviously broken?
Approved to ship?
Many teams pause here for a human, not to reread the code but to judge the moment. Nobody wants a risky release at five on a Friday. The strongest teams remove this pause entirely and ship on green, sometimes dozens of times a day.
Canary rollout to production
The deploy itself is gradual. A canary sends roughly one user in a hundred to the new version while everyone else stays on the old one. If it misbehaves, only that thin sliver of traffic ever notices, and you learn it from real users rather than a test.
Watch errors and latency
Now the pipeline watches: error rate, response time, memory, compared directly against the old version still serving most of the traffic. The canary gets a few minutes to prove itself before the rollout widens to half the fleet, and then to all of it.
Roll back to the last good build
And if the numbers turn ugly, the release is undone. Because the previous artifact is still sitting in the registry, rolling back is just pointing traffic at it again, often in under a minute. Being able to undo fast is precisely what makes shipping often safe.
The change is live for everyone
That is the bargain of continuous delivery. No heroic release nights, no big bang. Just one small change walking a well lit path that thousands of changes walked before it, which is why one person can ship on a Tuesday afternoon and then go for lunch.
Watch it explain itself
Every step above is narrated aloud. Play it, or open it in the editor and make it yours — no account needed.