The Release Checklist Every Dev Team Needs

A release checklist is the written list of steps your team follows every time software goes to production, from confirming scope to verifying the live system. It exists so nobody has to remember the database backup, the config change or the client email under pressure.

Pilots use checklists for routine take-offs, not because they forget how to fly, but because routine is exactly when steps get skipped. Releases are no different.

Before the release

These checks confirm the release is worth shipping:

1. Scope is frozen and every ticket in it is attached to the release.
2. Every ticket has passed testing, and the results are recorded.
3. A regression run has covered the areas around the change.
4. The client or product owner has signed off where required.
5. Database changes are scripted, reviewed and tested on a copy of production data.
6. Configuration and secrets for the target environment are confirmed.
7. A rollback plan exists, and someone has read it.
8. Stakeholders know the release window.

During the release

This is the runbook part. Keep it in strict order:

1. Announce the start in the team channel.
2. Take a backup of the production database.
3. Deploy to staging and smoke-test the key user journeys.
4. Deploy to production.
5. Run database scripts, then any data fixes.
6. Clear caches and restart services if your platform needs it.
7. Smoke-test production: log in, run the main user journey, check the changed feature.

Any step that fails stops the checklist. Either fix forward with a clear decision, or roll back. Our guide to runbooks explains how to write steps that someone else can follow at 11pm.

Shipping something soon? See how Flow turns releases into a checklist, not a gamble. Get started with Flow →

After the release

• Confirm monitoring and error logs look normal for the first hour.
• Mark the tickets as released, so anyone can see which version they shipped in.
• Send release notes to users and a summary to stakeholders.
• Note anything that went wrong and add a step to the checklist for next time.

Keeping the checklist alive

A checklist that never changes becomes wallpaper. Three habits keep it useful:

• Review it after every awkward release. If a step was missing, add it. If a step never matters, cut it.
• Make it resumable. Releases get interrupted. The checklist should show exactly which steps are ticked so the next person carries on.
• Keep one version per release type. A hotfix checklist should be shorter than a full release, not a full release done in a hurry.

For the bigger picture of planning and scheduling releases, see release management.

How Flow helps

In Jira, teams typically keep release checklists in a linked Confluence page or add them through a marketplace checklist app, since checklists are not a core part of Jira's version tracking. If you want a Jira alternative where the checklist lives on the release itself, Livex Flow provides:

• Release checklist and runbook steps that persist. Pause halfway, return the next morning, and every ticked step is still ticked. Nothing resets until you complete the release.
• Tickets attached to releases, with a view of which build or release each ticket shipped in.
• Test runs and client sign-off feeding the "before" checks with recorded evidence.
• A branded Excel release report and opt-in release notification emails for the "after" step.