Release checklist

Release checklist reduces the likelihood of known errors at the command junction: Adapt mandatory items to release risk, pre-assign a go/no-go decision owner, and make sure that rollbacks are not only described, but technically possible at the right time.

Why is it important to release checklist?

The essence of the release checklist

Release checklist is a short structured list that the team goes through before launching a new version, feature or product, and its goal is to reduce the risk of production errors, remember important steps, and increase the predictability of the release, a list used by large companies (Yandex, Google) and startups.

Example: When he saves

The real case: before the release of the mobile application, they forgot to turn on the crash recording in production - the problem was revealed on the release, they had to urgently fix it. If there was a checklist with the item “Error Monitoring” on it, the error is easily noticed in advance.

What should be on a good checklist

General structure of release checklist

A good checklist is built around specific release stages – code, testing, documentation, infrastructure, communication.

Example of structure:

1. Code - what to do with the repository, what is the status of the merjah
2. Tests – e2e run and regression, buglist, successful CI/CD run
3. Documentation – have the release notes, instructions to customers and the appendix been updated?
4. Infra – whether the dependencies have been updated, whether there are any monitoring losses, whether configuring is relevant
5. Communication – do you know the release time, made an announcement inside and key users
6. Rollback – is the instruction ready, can you roll back quickly

This basic order can be easily adapted to any product – mobile, web, SaaS.

Mandatory items for a typical IT product

Example of the main points for a common IT product:

• All pull-requests frozen, no blocking migrations
• Complete regression and critical auto tests
• All changes made to release notes
• Logging and alerts for new features are configured
• There is a rollback plan and test scenarios on rollback
• Coordination with relevant teams: sapport, marketing, Devops
• Changelog Updated, Version Number Updated Everywhere

Frequent errors

Many forget to add items like “Check production configs,” “Update the index in the app store,” “Check API backward compatibility,” “Perform a smoke test after release.” These details often cause incidents.

Release checklist: template for quick launches

Mini template of the release checklist (can be copied)

1. All the features in the release are completed and checked
2. Review code passed, in main/master only final assembly
3. CI/CD passed without errors, tests green
4. Laptops and Changelog Updated
5. Docker containers/builds signed with the correct version
6. Logs and monitoring for features included
7. Sanity check on staging and after production
8. The rollback plan is described and tested
9. Announcement for the team and customer support ready
10. Communication with the subsidiaries is complete

This template is suitable for web, mobile, b2b SaaS – as a starting point.

How to customize for your product

For each type of product (API, mobile application, internal system) it is useful to add 3-5 specific items:

• For API: Check backward compatibility and documentation versions
• For mobile: make sure to sign, check screenshots for App Store/Google Play
• For Internal Tulza: inform users, not break integration

Maintenance, updating and control of the checklist

Who and when is answering

The release checklist should not be a piece of paper for the report, but a workpiece of the team’s process, usually with the release manager or PM who is leading the release responsible for the checklist.

Control – before each depletion, someone responsible (assigned roles in Jira/Notion/Confluence) or the entire team at grooming/standup takes place.

How to update

The checklist should be updated after every incident, a bug report on the market or when processes change, and a separate section called Lessons learned after retro works well, and new items are added there.

Example: Adaptation after an incident

The product added a separate step after the incident, “Check the response speed of the main API methods immediately after rollout” – because this is what was missed earlier.

Automation of release checklist

Integration with CI/CD

Part of the checklist can be automated through checks in the assembly: tests, artifact assembly, run-through of the linters, the scripts notify if something goes wrong and prevent it from accidentally missing.

Use of templates

Most teams make checklists in Task Trackers (Jira, Notion, ClickUp) or as markdown documents with checkpoints, which speeds up the passage and does not require separate control.

Example of a template in Notion

Notion creates a template with checkboxes that the team takes turns to follow, and once released, you can quickly return to any point and track where the delay was.

FAQ on the release checklist

**Why do you need a release checklist if the team has few features? Checklist prevents even banal mistakes – no one is immune from forgetfulness at any number of tasks.

What are the mandatory items for any release? Code, tests, documentation, communication, monitoring and rollback plan, the rest of it is adaptation to the project.

Where is the best checklist - in a paper, a drag tracker or a wiki? It depends on the process. They use task trackers or electronic templates more often than not, so that they don’t lose anything.

*Can I automate the checklist? Code checks, tests, linters, depots and notifications can be closed automatically.

**What if you don’t find a product for your product? Take a typical template and add items for specifics: mobile, API, desktop, infrastructure, etc.

**Do I need to keep a separate checklist for bugfixes? Better - adapted short checklist with the main points: tests, release notes, deplo, notification of support.