Mitigating the Risk of Big-Bang App Releases

5 May 2021

This is a sketch . It might be rough, incomplete or without context.

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.

  1. Automated testing on key user journeys.
  2. Perform manual regression testing. Even if you have good automated coverage, the risk is high if it doesn’t work, so always check manually.
  3. 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.
  4. 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).
  5. 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.
  6. 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?’.
  7. 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.)