Deployment Checklist
What to verify before a change reaches real users, and why most of it should not be a checklist at all.
Overview
This document covers what belongs on a pre-deployment checklist, what should be deleted from one, the difference between a one-time readiness gate and a per-release gate, and the stop conditions that make a checklist a control rather than a formality.
Why This Exists
Most checklists fail in the same way: they restate what the code already validates. That version is theatre. It consumes attention, trains people to tick without reading, and provides assurance proportional to nothing. The useful test is narrow. **A checklist item earns its place only if the application structurally cannot verify it.** Everything else belongs in a startup gate, a test, or a type, where it cannot be skipped by someone in a hurry.
The test for whether an item belongs
Two different checklists
The release checklist
Stop conditions
Signing it means something
Related Principles· 2
Related Documents· 3
Referenced By· 4
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Establishes the test for whether an item belongs at all, separates the one-time go-live gate from the per-release gate, gives the short release list, and defines stop conditions and what signing asserts.