A software release can be daunting. Software engineers learn how to plan, code, build and test their software. However many aren’t taught about releasing and maintaining software.
In this article I want to share one of the simplest and most effective tools for planning your software release: The software release checklist.
I will not assume any prior knowledge for the last phases in our DevOps Lifecycle. If you have no clue about releasing software, this is for you.
The DevOps Lifecycle defines 4 phases after you have finished developing your software version:
As you can see, actually uploading and distributing the software is the next step, Deploy.
Before we get to that phase, we should plan, schedule and communicate our release. This may sound like a lot of management and, for big corporations, this is also the case. However if you are in a small business or startup, this can be solved with one of the easiest tools available.
A good software release is all about managing the process.
And the simplest way to manage a process is with a checklist.
I will share my release checklist with you, but keep in mind that you should alter it to suit your company and your software.
When I talk about the “app” or “software”, I mean the version, which we are releasing.
Assign every task in the checklist to exactly 1 person.
The responsible person for a task may change every release, but it is critical, that every task is assigned to someone. If that person only coordinates others doing the task, that is absolutely fine.
The important part here is to have exactly 1 contact person, in case things go wrong or you need a status update.
The following checklist is for a mobile App without a backend. It involves releasing to Google Play Store and Apple App Store.
As some of you may be new to App releases, I have gone into a little more detail here.
- Define new software version. (I recommend Semantic Versioning)
- Create release checklist for this software version in our Wiki/Google Drive/etc. It should be visible to everyone involved.
- Define target release date. This does not have to be communicated outside of your company. This is mainly for our internal planning.
- Define an “end of feature development” for the release. This is the deadline for new features. I recommend at least 1 week before planning your release (2-3 weeks, if releasing for iOS).
- A Maintenance Plan exists. Think about where people can report bugs and how you prioritise and fix them. This might include reading app store reviews and a support forum you may have. This can be a simple wiki page with a checklist.
- Inform marketing. This might be a team, a person, or yourself. Update your Presskit, prepare a tweet, prepare new screenshots.
- We have a release branch or tag in git for this software version. This helps us in case we must test old versions.
- Test android app.
- Test iOS app.
- Upload android app to Google Play Store.
- Upload iOS app to Apple App Store.
- Update Screenshots & Information in Google Play Store.
- Update Screenshots & Information in Apple App Store.
- The Apple Review was successful. This step may take several days, even 1-2 weeks if you must fix something. Take this into account when communicating deadlines.
- Release android app on Google Play Store.
- Release iOS app on Apple App Store.
For software releases without a backend, the post-release checklist is quite short. It basically consists of testing your released app and monitoring customer feedback
- Run Regression Tests on released Android App.
- Run Regression Tests on released iOS App.
- Define process for checking App Store reviews / support forums. Who checks these? How often?
All in all, software releases are a complex topic, which requires communication with many people. can be simplified
Looking for more inspiration? Yasmin Nozari has a post with more information on release checklists.