Posted by Peter Armitage, Software Engineer, Google Play

Releasing a new version of your app is an exciting moment when your team's hard work finally gets into the hands of your users. However, releasing can also be challenging - you want to keep your existing users happy without introducing performance regressions or bugs. At Google I/O this year, we talked about staged releases as an essential part of how Google does app releases, allowing you to manage the inherent risks of a new release by making a new version of your app available to just a fraction of your users. You can then increase this fraction as you gain confidence that your new version works as expected. We are excited that starting today staged releases will be possible on testing tracks, as well as the production track.

We will take a closer look at how staged releases work, and how you can use them as part of your release process.

Advantages of a staged release

The first benefit of a staged release is that it only exposes a fraction of your users to the new version. If the new version contains a bug, only a small number of people will be inconvenienced by it. This is much safer than releasing a new version to all of your users at once.

Another benefit is that if you discover a bug, you can halt the rollout, preventing any new users from downloading that version. Instead, they will receive the previous version.

These capabilities should relieve a lot of the uncertainty of rolling out a new version. And that will allow you to do it more often. We encourage releasing versions of a server more often because it reduces the number of changes between each release, allowing you to more easily test and troubleshoot. The same principle applies to apps, though there will be a delay before most of your users upgrade to the latest version.

Staged releases as part of your normal release process

Let's look at a typical release process for an app with 100,000 users.

1. Every Monday the developer builds a new version of the app from the latest version of the code that passes the automatic tests. They push the new release to Google Play's internal test track, and their QA team immediately starts testing it manually. Any bugs they find can be fixed and a new version can be built and pushed for them to re-check.
2. On Tuesday, if the QA team have approved the latest release, it can be promoted to the app's alpha track. All the employees at the company have opted in to testing. Once the new release is pushed to the alpha track, the employees can download the new version. They can do this manually, or they may have auto-updates enabled, in which case they will probably update within a few hours.
3. On Wednesday, if there are no reported issues with the release, they can promote the release to the production track and start a rollout at 10%. This means 10,000 users will have the opportunity to upgrade. Some will upgrade immediately, others will wait. The 10% of users that receive the app first are randomly selected, and the users will be randomly chosen each week.
4. On Thursday, the developer checks the Play Console to see their crash reports, Android vitals, and feedback. If these all look good they can increase the rollout to 100%. All users will be able to upgrade to the new version.
5. On Friday, the developer doesn't change anything, to ensure a stress-free weekend!

For big apps and small apps

Some apps are just starting out, and although there's no QA team, it's still worth testing the app on a few different devices before releasing it. Instead of having a track for employees, the developer has added their friends and family, who can contact them if they see an issue.

When an app gets larger and uses the open testing track, it may have 5,000 testers. These testers won't give public feedback on the Play store, but will be able to give feedback to the developer directly. If this app has 1 million users, they may first release to 1%, before going to 10%, then 100%.

Once an app becomes very popular, it could have over 100,000 testers. In that case the developer is now able to do a staged release on their testing track.

How to bounce back from issues

Bugs happen, and if you discover a problem with your new version you may want to halt the release. This will stop users from getting the new version, either by upgrading or installing for the first time. However, those who have already got the new version will not downgrade.

If the issue was not in the app itself, but on a server that the app communicates with, it may be best to fix the issue in the server, then resume the release. Resuming it allows some fraction of your users to access the new version again. This is the same set of users that were able to download the release before it was halted.

If the issue was in the app, you will have to fix it and release a new version. Or alternatively, you may choose to rebuild the previous version with a higher version code. Then you can start a staged release to the same set of users that the previous release went to.

API support

Staged releases are supported in v3 of the Play Console API on all tracks. Mark a release as "inProgress" and set a fraction of the population to target. For instance, to start a staged release to 5%:

{
  "releases": [{
      "versionCodes": ["99"],
      "userFraction": 0.05,
      "status": "inProgress"
  }]
}

Alternatively, if you release using the UI, it will suggest a fraction.

What next?

We hope you find these features useful and take advantage of them for successful updates with Google Play. If you're interested in some of the other great tools for distributing your apps, check out the I/O 2018 sessions, and learn more about test tracks and staged updates.

How useful did you find this blogpost?

★ ★ ★ ★ ★