session · build & review
Release gate review
20 minutes. A state check, not a meeting. Every gate item is either met or named. No item is hand-waved. A failed gate is a held release.
When
- Before flag enablement, never during. The gate is a precondition, not a retrospective.
- For every release — typo-fix lightweight track has its own micro-gate (CI green, conventional commit, no production touch); full releases get the full gate.
Who
- PO — owns the calendar and the brief side.
- Tech Lead — owns the technical readiness.
- On-call for the next 48h — must be present and signed in.
- (For high-blast-radius releases) CS Lead also present, confirming the CS Handoff is ready.
Time-box
20 minutes. Anything longer means an item isn't ready — close the gate, schedule the missing work, re-gate when complete.
Inputs
- The Release Gate checklist.
- The release brief (draft) to the client.
- The CS Handoff document.
- The runbooks for the affected services.
- The dashboards the first-48-hours watch will use.
Agenda
Walk the gate checklist, line by line. Each item: met / not met / waived with named follow-up.
| Gate item (canonical) | Owner |
|---|---|
| Three-confirmation review approved | PO/QA/Designer |
| All Gherkin scenarios pass in staging | QA |
| Visual regression baseline approved | Designer |
| Security scan: zero high/critical findings | Tech Lead |
| Performance: load test at SLO threshold passes | Tech Lead |
| Migrations: rollback rehearsed in staging this week | Tech Lead |
| Feature flag wired with default-off; cleanup task filed with date | Tech Lead |
| Runbooks updated and last-tested within 90 days | On-call |
| Dashboards baseline-captured; SLIs visible | PO |
| Release brief to client drafted | PO |
| CS Handoff written and walked with CS Lead | PO + CS Lead |
| On-call rotation confirmed for the next 48h | On-call |
| Prediction check date in the calendar | PO |
If all green → release proceeds at the named window. If any not green → release is held; named follow-up; re-gate within 24h or sooner.
Outputs
- A signed gate record — checklist with status per item, signatures, dated.
- Decision — proceed at [window] / held pending [item].
What good looks like
The gate ends in 20 minutes because the items are checked progressively as the release approaches, not in the gate session itself. The gate is discovery of state, not creation of state.
A waived item is rare and explicit — "Visual regression baseline waived; one storybook diff is intentional, signed by Designer; new baseline captured at release." Waivers have signatures. Hand-waving does not.
Anti-pattern
The gate becomes a negotiation about whether to ship. Items are reframed as "not blockers" to avoid delay; the release goes out with quiet known gaps. Fix: the gate is a state. Either the state is met or it isn't. If we want to ship anyway, that is a waiver, signed, with a follow-up.
A second anti-pattern: gate items get checked off without anyone actually checking. The release goes out; the JWT outage ships; the postmortem reveals that the migration-rollback rehearsal was a checked box not a real rehearsal. Fix: each gate item names what evidence proves it — a PR link, a CI run, a calendar entry, a Slack thread with the CS Lead.
See also
- Canon — How We Build · The Release · the gate
- Template — Release brief to client
- Checklist — Release gate · state-not-meeting
- Practice — Release gate
- Next session — First-48-hours watch (begins at flag-on)