In this guide 6 sections
A production release checklist is a short go or no go list signed before the deploy starts. It confirms the artifact is the one tested. It checks that migrations can be reversed, flags are set, smoke tests are scripted, customers are told and someone watches afterwards.
Confirm the artifact is the one you tested
Start with the thing being shipped. It should be a single build, a container image or a zipped bundle, with a version tag and a commit hash written on the release ticket.
Rebuilding on the day is a classic trap. A fresh build can quietly pull a newer package and ship code that nobody ever tested on staging. Promote the exact image instead.
An approver who is not an engineer can still check this. Ask for the tag on staging and the tag queued for production. They must match.
- Version tag and commit hash on the ticket
- Image digest identical on staging and production
- Lockfile unchanged since the last test run
- Release notes listing each merged pull request
Check migrations and flags before anyone clicks deploy
List every database migration in the release and mark each as additive or destructive. Adding a nullable column is gentle. Dropping a column or renaming a table can break the old code that is still running during the rollout.
Feature flags need the same care. New behaviour should ship switched off, then be turned on for staff first and customers later. Write down the flag names, their starting state and who may flip them.
Run the migration against a recent copy of production data. Note how long it took. A step that runs in seconds on a laptop can lock a large table for minutes.
- Migration marked additive or destructive
- Time taken on a production-sized copy
- Flag names and their default state
- Owner who may switch each flag
What to do during the deploy itself
Pick a window when traffic is low and the right people are awake. Friday evening releases are a poor choice. Name one person who runs the deploy and one who watches the dashboards.
Run the smoke tests the moment the new version is live. They should be short and scripted: log in, load the home page, create a record, take a payment in test mode, send an email.
If a smoke test fails, stop. Do not debug on live users. The decision to roll back belongs to a named owner, not a group chat.
Tell customers and support before the release, not after
Support staff hate surprises. Send them a plain note covering what changes on screen, what might look odd for a few minutes, and what to say when a customer rings in.
For customers, a banner or a status page entry is enough when downtime is expected. Silence is worse than a short outage that was announced.
Keep the wording plain. A shop owner does not care about a cache flush.
Watch the first hour and close the ticket properly
Releases fail slowly as often as they fail loudly. Watch error rates, response times, queue depth and the failed-payment count against the numbers from the previous day. A quiet climb is a warning.
Hold the release ticket open for a fixed period, such as one hour for a small change or a full business day for a large one. Close it only when the numbers look normal.
Finish with a two-line note on what surprised you. Add one item to the checklist from it. This week’s mistake becomes next week’s tick box.
- Error rate and latency against yesterday
- Failed payments and failed logins
- Background job queue length
- Support inbox for new complaint patterns
Go or no go release sheet
A one-page sheet in three columns: before, during and after. Rows cover artifact tag, migration list, flag table, smoke test results, customer notice sent, rollback owner and watch period. Every row carries a tick box, the initials of whoever checked it and the clock time. The approver signs at the bottom.
Open a blank worksheet to printQuestions owners ask
Who should sign off a production release?
One accountable person, usually the engineering lead or product owner. They should be able to read the sheet without reading code. A second person, who is not the author, checks the artifact tag and migrations.
How long should a smoke test take?
A few minutes at most. It checks that the main paths work, not that every edge case does. If it takes longer, people skip it under pressure.
Should every release have a rollback plan?
Yes, even a small one. Write the exact command or button, the person who decides and the point at which you stop trying to fix forward. Migrations are the usual blocker.
Can a small team skip this checklist?
Shrink it, do not skip it. Five lines on the ticket still catch the rebuilt-on-the-day artifact and the unannounced downtime, which cause most avoidable incidents.