Template preview · Software
Release rollout
Ship a change in controlled stages with explicit evidence.
A staged rollout plan for a fictional product release.
Sample purpose
Ship a change in controlled stages with explicit evidence.
Audience: Release manager, Engineering manager- Structure
- 4 sections
- Criteria
- 15
- Sources
- 9
- Watches
- 4
- Default approach
- Review first
Set the purpose first. Then change every section, criterion, and agent setting before anything runs.
Fictional sample
Structure and criteria
Sample content shows the shape of a useful document. Copying it is optional.
01 Review firstRelease scope
State what is being released and what is excluded.
Criteria
- States the change in member language ('members can book conference rooms')
- Lists at least one exclusion with a reason
- Names one owner for scope changes
- Names which sites or segments receive it
Sources
- Google SRE: release engineering sre.googleSeparating release scope from risk controls.
- Harbor Desk release decisions (fictional) api.harbordesk.exampleRatified exclusions and change requests.
Sample content
Harbor Desk will release room booking to two fictional sites. Calendar migration and invoice integration are explicitly excluded. Release owner: Mina.
02 Review firstRollout stages
Define stages, entry evidence, and pause conditions.
Criteria
- Each stage has a checkable entry condition (20 staff bookings succeed)
- Each stage has a numeric pause trigger (cancellation rate above 10%)
- Stages go from internal and few sites to all members
- Each advance needs a recorded approval from the release owner
Sources
- Google SRE Workbook: canarying releases sre.googleStage gates and canary evaluation.
- Harbor Desk rollout incidents (fictional) api.harbordesk.exampleWhich thresholds worked in past rollouts.
Watches
- Follows Release scope
Sample content
Stage Entry evidence Pause when Pilot 20 staff bookings succeed Cancellation rate exceeds 10%. Two sites Pilot support volume stable Any double-booking confirmed. 03 ManualRelease checks
Make preflight and recovery actions explicit.
Criteria
- Includes a rollback drill already completed before stage 1, with evidence
- Each check has one named owner
- Checks use test accounts or staging, never member data
- At least two checks cover member-visible behavior (confirmation email, calendar sync)
Sources
- Harbor Desk QA procedures (fictional) api.harbordesk.exampleTest cases and staging access.
- Harbor Desk rollback runbook (fictional) api.harbordesk.exampleManual recovery steps to rehearse.
Watches
- Follows Rollout stages
Sample content
- ☐ Mina verifies booking confirmation email
- ☐ Omar verifies rollback flag works
- ☐ Support lead approves customer notice
04 Review firstRollout measures
Track the few signals that determine whether to continue.
Criteria
- Includes a member-success metric and a safety metric (double bookings)
- Every metric has a baseline, a pause threshold and a review window
- Support tickets are watched beside automated metrics
Sources
- Prometheus alerting practices prometheus.ioAlerting on symptoms rather than causes.
- Harbor Desk rollout dashboard (fictional) api.harbordesk.exampleLive stage metrics.
- Harbor Desk booking tickets (fictional) api.harbordesk.exampleSupport volume by reason.
Watches
- Follows Rollout stages
- Searches “room booking double booked calendar sync problem” weekly
Agent may search the web.
Sample content
- Successful booking rate
- 96%
- Double-booking reports
- 0