Improving the Release Process

[sdsantos]

The goal of this issue is to discuss what could be improved in the Probe app Release Process. Once we agree on an approach, this can become the Epic to track the necessary tasks.

---

Pull-requests merged into the main branch should trigger new Probe Android and News Media Scan Android builds automatically to Firebase.

To release a new version of the app could be:

• Create a release branch / pull-request with:
  • New version numbers/codes
  • Release notes
  • Translations updated
• An automatic closed testing release of Probe Android and NMS Android to Google Play

Once the new builds are approved for release:

• Merge the release branch into main
• Tag the latest commit with the version
• Create a release on Github based on the tag (write the release notes there as well)

Creating a new release on Github should trigger:

• An automatic deployment of Probe iOS and NMS iOS to the App Store
• An automatic promotion of the release from closed testing to production of NMS Android to Google Play
• An automatic promotion of the release from closed testing to open testing of Probe Android to Google Play
• F-Droid should pull and build the new release automatically
• A Slack message to #ooni-mobile stating that the new version X.Y.Z is being released

The developer responsible for handling the release should keep an eye on the deployment actions to see if they complete smoothly. And the mobile team should keep an eye on Sentry for any increase in activity.

After one week, if the release goes smoothly, we should promote the Probe Android app from open testing to production on Google Play, rolling it out in percentages.

---

We also need to ensure that we're uploading debug symbols to Sentry. Could be automated when we create the release branch.

---

Please comment with feedback @hellais and @aanorbel.

[aanorbel]

I think it would be better to disable automatic publishing and submit the app to internal testing and review in parallel.

Once we do the internal testing and confirm everything is correct, we can then publish the app.

it would be better to test release builds from google play.

[sdsantos]

I think it would be better to disable automatic publishing and submit the app to internal testing and review in parallel.

Once we do the internal testing and confirm everything is correct, we can then publish the app.

it would be better to test release builds from google play.

So, when we create the release branch, publish Probe Android and NMS Android to "internal testing" or "closed testing" on Google Play, instead of Firebase? And then when we merge the release branch, we just promote those builds, manually or automatically?

[aanorbel]

• Development builds go to firbease.
• Release candidates go to the store.
  • They can be promoted to production (Tested binary is the one actually deployed.).

Slight problem here since f-droid would not get so much love

[sdsantos]

Development builds go to firebase.

I'll document that above, that PRs merged into main should be deployed to firebase automatically.

Slight problem here since f-droid would not get so much love

You're right. The F-Droid only has slightly less features, so it's not crucial that it gets dedicated QA. But ideally we would test it some part of the process. We could make development builds also go to a Firebase F-Droid app, but would we test it often realistically?

[aanorbel]

We need to find a way to include fdroid in the build matrix for development so it gets tested often.