What to check before every release
A release checklist earns its place by being short enough to run every time. Here is the one we hand teams on day one.
Most release checklists fail the same way. They start useful, someone adds an item after every incident, and eighteen months later the list takes ninety minutes and gets skipped on the day it matters most.
A checklist that is skipped is worse than no checklist, because the team believes it ran.
Keep it under fifteen minutes
That is the real constraint. Not completeness. If the list takes longer than a coffee break, somebody under deadline pressure will tick it without running it, and you will not find out until the incident review.
Everything that does not fit goes into the regression suite, where a machine can afford the time.
The list
- Sign-up and login, including one existing account and one new one. If people cannot get in, nothing else on this page matters.
- The one flow that takes money. Checkout, upgrade, whatever it is for you. Run it end to end with a real card in the test environment.
- The feature you actually shipped, in the environment you are shipping to, by someone who did not write it.
- One mobile pass over the two flows above, on a real phone.
- The error paths you touched. Wrong password, declined card, expired link. Bugs hide in the unhappy path because the happy path gets all the attention.
- A look at the logs for five minutes after deploy, at the error rate rather than at individual lines.
The parts people forget
Two items go missing from almost every list we are handed:
- The rollback. Not "can we roll back" in theory, but who runs it, with what command, and how long it takes. Write it at the top, not the bottom.
- A check that the old version still works for people mid-session. A user who loaded the page before the deploy is running your previous front end against your new backend.
Who runs it
Not the person who wrote the code. That is the whole argument of why developers can't test their own code, and it applies at release time more than anywhere else, because this is the last chance anyone has to look with fresh eyes.
If your team is too small for that, swap: whoever shipped feature A runs the list for feature B. Any second pair of eyes beats none.