The deployment pipeline
Defined by Jez Humble and David Farley in Continuous Delivery: ensures every commit is automatically built and tested in a production-like environment. Build, test, integration errors are caught the moment they're introduced — when the cost of fixing them is lowest.
Every commit to version control kicks off the pipeline. It packages the software, runs tests, deploys to a production-like environment, and reports back. As the practice matures, the same pipeline also drives UAT, security testing, and the path to production.
- — Build + package the software.
- — Run automated unit tests.
- — Static code analysis.
- — Duplication + style checks.
- — Test-coverage reporting.
// fast. minutes, ideally under 10.
- — Deploy commit-stage package to prod-like env.
- — Run automated acceptance tests.
- — On green, make build available for UAT, integration, security testing.
- — Eventually, gate or trigger production deploy.
// slower. minutes to hours, OK.
Open source and SaaS options, mostly interchangeable for the foundational pipeline:
// pick by org constraint (org policy, hosting, language ecosystem) — the pipeline pattern is the same.
16k from humans · 24k from automation
90k+ on weekdays
~75M test cases run daily
~35M commits historical
files visible to all full-time engineers
9M unique source files
The takeaway isn't "be Google." It's that the pipeline pattern scales nearly without limit — and that the practices in Modules 04–06 are what make 40,000 commits/day not burn the company down.
A team's commit stage takes 35 minutes. What's the predictable failure mode?
// pick one to verify
A team has a pipeline but their acceptance stage runs against a hand-configured staging server that gets re-imaged twice a year. Why is the pipeline still vulnerable?
// pick one to verify