Release Plan is an essential part of a software plan. Most of the Product Owners focus on:
- what will be part of release,
- when will it be released,
- who will do the release.
All of the above are the must haves of the release plan, however while doing an upgrade of a system which is being used by users already, there are some other essential points as well. We sometimes forget about these in planning activities but those are must have for each release.
Duration of Maintenance Window
It’s very important to identify how much time is needed to do all the activities involved in the deployment including the sanity testing. The duration of the maintenance window keep everyone updated on expectation. If the clients know that it’s going to take 1 hr to do the upgrade, they won’t ping every 15 mins anticipating the worst.
2. Maintenance Page
Maintenance page is a way to inform users that there is nothing wrong with the application. Specifying the maintenance window in maintenance page itself will stop user from going in frenzy and wondering when can they try again.
3. Pre-Release Message/ Pre-Downtime Warning
Other then keeping the maintenance page, the best user experience comes in when users do not encounter something which they didn’t anticipate. A Pre-Release/ pre-downtime message somewhere in application (may be on top of the application where it is noticeable) few hours/ a day before release time, will set the right expectation with end user.
On the other hand as people know that downtime is near, they won’t be active and hence your worry that while deployment some user activity data is getting lost will also be handled.
4. How the DB updates be done.
Always plan the DB updates in scripts. It’s important for each release the script is kept specific to release ready to be deployed. Even the data changes should go in separate script which was tested on pre-prod/staging environment.
5. How to handle the cron/scheduled activities
One should always keep a tab on scheduled jobs/cron. Are there any cron jobs running at the time of deployment? Are there any updates in cron job timing/parameters/call in this release?
Also always make sure that there is a step to disable the schedule in start of the deployment and enable at the completion of release.
6. How will the rollback happen in case of failure
It’s important to always plan how will the code be updated and how will be DB be rolled back in case of failure. Usage of CI/CD and DB migrations, makes the rollback process very easy.
7. Testing before exposing to the world
With this I come to last and very important point which gets missed almost all the time. When we complete the deployment, the maintenance window is brought down and application is available for testers to do the sanity. However, what we miss is that it’s also released to entire world and users now have started to use it.
If at this point there is a blocker identified in release, it can’t be rolled back. As in rollback the users data entered between the duration when maintenance was brought down and when the tester identified the issue( which can be an hour or 2) will be lost.
Hence it’s always good to plan in such a way that the application first exposure is to only a handful of people. This could either be with IP specific release, or with feature enabling strategy or even Canary release can help in this case.