Deployment Pipeline
The automated path from commit to production, structured so that each stage increases confidence and the whole is fast enough to be run on every change.
The pipeline is a product with users, and its most important property is speed: a pipeline slower than about ten minutes to feedback changes behaviour, because developers stop waiting for it and start batching changes — which makes every failure harder to attribute.
A workable structure, fast stages first: build and unit tests (minutes); static analysis, security scanning and architecture fitness functions; integration and contract tests; deploy to a staging environment; automated acceptance tests; progressive production deployment with automated verification.
Principles that separate a pipeline from a script:
Build once, promote the same artefact. Rebuilding per environment means the thing tested is not the thing deployed.
Configuration by environment, artefact identical, or the pipeline proves nothing about production.
Fail fast — order stages by speed and by likelihood of catching a problem.
Every commit runs the pipeline, which is what makes continuous integration continuous.
The metrics that reveal whether it is healthy are the DORA four, and the two most diagnostic are lead time and change failure rate. A long lead time usually points at a slow pipeline or manual gates; a high change failure rate points at insufficient verification or batch sizes that are too large.