Path to Production Diagram
Commit to live drawn as it actually runs — build once and promote, the verify step teams skip, the rollback that has to be tested, and the four measures that tell you whether any of it is working.
SVG. No sign-up, no email.
The value of a delivery pipeline is not that it automates deployment. It is that it makes the distance between "a change exists" and "a change is live" short enough to be boring. The diagram below is the shape that achieves it, with the two boxes that are most often missing.
Build once, promote the same artefact#
The first shaded box is the discipline the whole lane depends on. Build one artefact, once, and promote that exact artefact through test, staging and production.
Rebuilding per environment reintroduces the problem the pipeline exists to remove: what runs in production was never the thing that was tested. Dependencies resolve differently a week later. A base image moves. The build machine changed. Each is individually unlikely and collectively routine, and the failure appears as "it worked in test" — the least useful sentence in operations.
Configuration is what varies between environments, injected at deploy time. The binary does not vary.
Verify is a step, not a feeling#
The second shaded box is the one most pipelines omit. A deployment that reports success has proved that files moved. It has not proved that the application works.
Verification is a small, specific check that runs immediately after deploy: a real request through a real path that touches the things a deploy commonly breaks — configuration, database connectivity, a downstream dependency. It takes seconds and it converts "we think it is fine" into a fact, before the traffic arrives to find out for you.
The rollback has to be tested#
Marked as a warning because of how it fails. Almost every rollback procedure is written. Very few are exercised. The most common reason an incident lasts hours instead of minutes is discovering, during the incident, that the rollback does not work — the previous artefact was cleaned up, the schema change was not backward-compatible, or nobody present has the permission to run it.
Test it on an ordinary day when it does not matter. Note also the constraint it puts on the lane above: database changes must be backward-compatible, or rolling the code back leaves it running against a schema it does not understand. Add columns before using them; remove them a release later.
Measure, then change#
The bottom lane is deliberately drawn as a set rather than a sequence. The four measures are independent, they are the only honest description of delivery performance, and they can all be recovered from existing records — a spreadsheet is enough to start.
Measure before changing anything. Every improvement below is worth doing, but only the numbers tell you which one is worth doing first, and only they will tell you afterwards whether the tooling you bought made any difference.
Using this diagram#
Mark the boxes you have. The usual gaps are: rebuild per environment rather than promote, no verify step, an untested rollback, and no measures. Closing them in that order shortens incidents before it shortens lead time — which is the right way round, because the cost of a long incident is paid in front of customers.