A big-bang app release is where you release a significant change, or re-write, to a significant number of users. These are high-risk because app releases can’t be rolled back.
It’s a good idea to avoid these where you can, but it’s not always possible. Here are some thoughts on mitigating the risk when it’s unavoidable.
- Automated testing on key user journeys.
- Perform manual regression testing. Even if you have good automated coverage, the risk is high if it doesn’t work, so always check manually.
- Run a beta test with a group of users. Your users will tell you what they think. Get them to tell you in a beta, so it won’t affect your store ratings.
- Keep the old codebase running and releasable, if you can. Have a build ready and approved in case you need an emergency fix-forward roll-back. This isn’t always possible or worth the effort (e.g., if the version was targeted a very old OS version, or if the old app had been rejected by the store).
- Use a phased roll-out. Pause it after 1% and monitor it. Increase the roll-out steadily when you’re happy everything’s OK. Beware though, if you find and fix an issue, then release the fix on a new phased roll-out, it will be rolled-out to a new, random population. This means broken users might not get the fix until the end of the roll-out.
- Implement operational analytics, and a dashboard that lets you see if the app is working. You need to monitor things like sessions; logins; completed flows. You need to be able to answer the question ‘Is it working?’, and, if it isn’t, ‘What’s not working?’.
- Once the big-bang release is over, continue with small, iterative releases to keep the risk small. (See Find the Right Release Strategy for Your Mobile App for more information on release strategies.)