DEV Community

Hive80-lab
Hive80-lab

Posted on Originally published at hive80-lab.github.io

The release checklist for small teams: twelve boxes between green build and shipped

A release checklist is not paperwork — it is the memory of your last three bad Fridays, written down while the pain was fresh. Every box on a good one exists because somebody once shipped without it: the migration that could not be un-run, the flag that never got set for gradual rollout, the Friday 5pm release with no note and no owner. For a team under twenty, twelve boxes is enough — if every box has a name attached to it.

1. The twelve boxes

The late boxes are the ones teams actually forget:

  • Backups are fresh, and the restore was tested recently — the release that touches data is the one that will need it.
  • Monitoring covers the change. New queue? New endpoint? If it cannot be observed, it cannot be rolled back on evidence — the golden signals need a row for it.
  • Timing chosen on purpose. Not Friday 4:55pm by default; the window matches the blast radius, and anyone on call knows the release is coming.
  • Comms ready before the deploy — release notes drafted, and if customers feel the change in real time, the status page is warm.
  • One person owns the ship. A name, not "the team." If it goes wrong at 17:40, the decision-maker is already written down.
  • The abort decision is pre-made — the exact signal (error rate, queue lag, ticket count) that stops the rollout, agreed before anyone has to argue thresholds mid-incident.
  • Post-ship watch exists — who watches the dashboards for the first 30 minutes, and what happens at the end of it: ship closed, or incident opened.

The earlier boxes gate the change itself: review sign-off, the tested undo, the flag set for gradual rollout.

2. The shortcut: most releases check nine boxes in five minutes

The checklist dies if every typo fix needs twelve signatures. The risk class from change review sets the depth: a Class 4 change (no data, no auth, no money) checks boxes 1, 5, 8, 10 — ninety seconds, ship. Class 1–3 gets all twelve. And data and auth changes ship early in the day, never last-thing Friday.

3. Five traps

  • The checklist as memory test. If the boxes live in someone's head, the checklist is that person — and it does not scale past their vacation. Written, versioned with the repo.
  • Checkbox theater. Twenty boxes ticked in thirty seconds is a signature, not a review. If a box cannot honestly be checked (nobody knows the rollback), the mark is "not done" — and the release waits.
  • Checklists that never change. Every post-mortem donates one candidate box; the checklist accepts at most one new box per month, or it bloats into noise.
  • The same depth for every release. Twelve boxes for a typo fix teaches the team that checklists are rituals — then the one release that needed all twelve gets a skimmed one.
  • Checklist as substitute for rehearsal. Ticking "rollback rehearsed" is not the rehearsal. The box marks that the rehearsal happened, recently, on something production-like.

4. Worked example

A ten-person project-management SaaS shipped weekly with no checklist. The quarter's wounds: a migration that added a NOT NULL column with no down-path — seven hours of recovery and an emergency data backfill — and a billing change that went straight to customers. They adopted the twelve boxes in one afternoon, attached to the PR template. The next month, the next one-way migration was caught at box 2 and rewritten as two reversible steps.

5. Metrics for the checklist itself

  • Every release attaches the checklist, and the depth is visible: four boxes for Class 4, twelve for Class 1–3.
  • Zero one-way migrations without a written reason.
  • Abort signals pre-agreed for every flagged release — flags flipped by signal, not by debate.
  • The checklist changes at most once a month, and every change cites the release that taught it.
  • Time-to-complete for a normal release stays in minutes. If checklist time grows, the boxes have become theater.

The full template (copy-paste HTML, twelve boxes with owner fields, the risk-class shortcut table, the worked example) is free on HIVE80lab Ops Notes.

If you want the surrounding kit — incident response plan, severity matrix, post-mortems for a 1–50 person team: the Ops Starter Kit ($14), Vol. 2 ($27), the Ops Mega Bundle (all five kits), and The First 30 Minutes is a free incident quick-start.

Top comments (0)