Deployment Process Documentation Template
Four documents and three sheets that compute the block rate at every pipeline stage, so you know which approval actually catches anything.
Free download · No account needed
Approval Gates
Four stages block something. One decides in under a minute and blocks nothing at all
| Stage | Entered | Blocked | Rate |
|---|---|---|---|
| Automated Test Suite | 1,240 | 187 | 15.1% |
| Staging Smoke Test | 1,053 | 41 | 3.9% |
| QA Manual Sign-off | 1,012 | 21 | 2.1% |
| Change Advisory Board | 991 | 0 | 0.0% |
| Canary Analysis | 991 | 28 | 2.8% |
Zero blocked is not the same as clean
The Change Advisory Board approved every one of 991 requests in a median of 47 seconds, and skipped its own rollback-plan check on 21.6% of them.
Thistledown Systems, a subscription billing platform, ran six months of its own deployment history back through its release pipeline's five stages rather than trusting the stage list on its own. Of 1,240 deployment attempts, every automated stage blocked a real, consistent share: 15.1 percent at the automated test suite, 3.9 percent at the staging smoke test, 2.8 percent at canary analysis. Its Change Advisory Board approval, the one human sign-off in the pipeline, blocked zero of 991 requests over the same six months, deciding in a median of 47 seconds.
A zero-block rate alone could mean the gate is simply redundant with the checks around it. Thistledown's own approval charter names a specific, checkable requirement instead: confirm a rollback plan is attached before signing off. 214 of the 991 requests, 21.6 percent, were approved with no plan attached, meaning the one item the approver's own checklist asks for went unchecked on more than one release in five. DORA's 2019 Accelerate State of DevOps Report found this pattern industry-wide: an external approval body carries no measurable gain in stability and a real cost in speed.
The gap is not abstract. Nine of the window's shipped releases needed an actual rollback rather than a forward-fix hotfix. The six with no plan attached took a median of 52 minutes to execute against 11 minutes for the three that had one, a 4.7x difference on the identical operation. That is the change failure rate DORA's own metric guide defines, split by the one variable a pipeline diagram never shows: whether the approval that let the release ship actually checked anything on the way through.
What is in the pack
Environment Definitions
What each environment in the pipeline is for, who can reach it, and specifically where it differs from production in a way that could hide a real defect.
Pipeline Diagram
The stage-by-stage flow of the deployment history with entered, blocked, and block rate at every stage, and the one stage that breaks the pattern.
Release Procedure
How a change actually reaches production today, written from the deployment history rather than the aspirational description of the pipeline.
Rollback Guide
One entry per rollback mechanism, with its measured duration split by whatever condition the data shows actually changes it, not a single blended estimate.
Environment Register
One row per environment: purpose, data source, who can deploy, who can view, and how it differs from production.
Deployment History
One row per attempt, with its outcome at every stage and whether it needed a hotfix or rollback afterward.
Approval Gates
The computed result: entered, blocked, and block rate at every stage, which is the sheet that turns a diagram into a verdict.
How it works
- 1
Open it in River, or download it
Edit with AI opens the pack as a private Space with the agent ready to run the joins. Download hands you four Word documents and three CSV sheets, no account needed.
- 2
Send the pipeline configuration and the history
The CI/CD configuration and as much deployment history as you can export, ideally a few hundred attempts with the outcome recorded at every stage.
- 3
Get the block rate at every stage
River joins the history against the stage list and computes entered, blocked, and block rate per stage, including whether an approval checklist item was actually satisfied.
- 4
See which gate the post-ship failures would have caught
Every release that needed a hotfix or rollback gets checked against which stage's scope should have caught it, and which stage actually let it through.
Frequently asked questions
Is this template free?
Yes, and the download needs no account, card or email. Edit with AI is the optional half that runs the joins: reconstructing the deployment history stage by stage, computing the block rate at every gate, and attributing every post-ship failure to what the pipeline missed.
What format are the downloaded files?
Four documents as .docx and three sheets as .csv, in one zip. Word, Pages, Google Docs, Excel, Numbers and Sheets open them with nothing to convert. The sheets carry the worked Thistledown Systems example, so the arithmetic is visible before you replace it with your own.
We already have a deployment runbook template. What does this add?
A runbook tells you what each stage is supposed to do. It has no source for whether any stage actually does it. Thistledown's own Change Advisory Board approval blocked zero of 991 requests over six months and skipped its own rollback-plan requirement on 21.6 percent of what it approved, a fact no runbook's rollback section would ever surface on its own.
Does a zero-block approval stage mean we should just remove it?
Not as the first move. A zero-block human approval usually exists to satisfy an audit or compliance requirement that has nothing to do with catching defects. State plainly what the stage is actually accomplishing, separately from what it is failing to accomplish, and let whoever owns that requirement decide if the first justifies the second.
How is this different from an infrastructure-as-code review, a load test report, or an infrastructure inventory?
Three different questions, not variations on one. An infrastructure-as-code review reads what the Terraform or CloudFormation code provisions, and a load test report reports whether a build met its SLO under load; neither reads the approval step in between. An infrastructure inventory resolves who owns what is currently running, which this pack assumes rather than re-derives.
What catches a problem this pipeline's gates all missed?
Nothing in this pipeline, by design. A stage that was never scoped to catch a category of defect is a different finding from one that fails at its own job, and this pack keeps the two separate rather than blaming the nearest gate. Whether your monitoring would catch either kind after the fact is a separate observability coverage review.