Figure out a managed release process

[lukesleeman]

At the moment everything merged to master gets rolled out to everybody signed up for testing. This is great for quickly iterating, but if we are to ship this "to production" we are going to need a more managed process for promoting a particular test build to prod.

This is for medical and ethical reasons: We need to have at least one of the WH medical staff test and approve the build before it is widely released.

We need to design some kind of process for a build being promoted. Ideally there should be some kind of button which does it, which can only be clicked by one of the medical staff - but any kind of process which involves getting a sign off by the medical staff is fine.

I'm interested in hearing from @maks and @workerbee22 about what kind of technological options our current CI and build pipeline setup can give us.

A nice have would also be to include other input in the process such as design signoff, qa signoff, etc

[workerbee22]

@lukesleeman @maks and everyone. So MAks and myself has discussed this a fair bit as we are doing all the CI/CD things. I guess we can summarise the approach right now as follows:

Objectives

• Speed of development and release is obviously an objective, given we are racing against the speed of the virus outbreak. To support this we are leaning heavily on automation and CI/CD setups. We also don't want the release process to be too 'deep' with too many steps to go through to get a release out, but this needs to be balanced with appropriate rigour.

• Consistency - We have a large number of people in the team with many on the lower end of development team experience and/or working part time. This may not be ideal, so again leaning on automation to remove possible mistakes through manual processes whenever possible.

• Quality - Having @greggmiller and other medical staff engaged as much as possible and be key to sign offs & approvals.

Implementation

Thinking about the release process in at most 3 layers:

1. Development Releases

Audience for consuming these releases is primarily all developers, but also medical staff like Gregg to get visibility of progress and provide feedback etc. as we develop.

Devs should work in their PR branches and test locally, both for Debug and Release builds before even committing. So we perhaps should be doing more local Release builds, so we don't waste codemagic build minutes, just because we want a Release build. That can be done locally by developers BEFORE they commit. Then we have PR branches that once approved get pushed to Master, built and tested. Any dev can also be on the list to get the Firebase App Distribution on Android, with TestFlight for iOS very close to being live.

2. Beta Release

Audience for consuming these releases is primarily medical staff to do testing. Not just out 'product owners' like Gregg but his colleagues x many

Beta releases to be the codemagic builds that go to Google Play Beta for Android and TestFlight for iOS. These two release channels are the easiest for this audience to install test with.

3. Production Release

Audience for consuming these releases is general medical staff who use the app.

Google Play for Android and Apple AppStore for iOS releases. Will need to get Gregg or others to monitor store feedback, issues raised and star ratings.

Processes for each level:

• Development Releases are fully automated
• Beta Releases are currently 'manual' kickoff of builds but will look at if we automate this. We may need to keep these manual and then ask Gregg and others to manually test and signoff before we distribute to other testers.
• Production Releases will need Gregg signoff and possible others before they are releases to the app stores.

Thoughts?

[maks]

I'm happy with those suggestions @workerbee22

My 2c: good to keep things as simple too. With release to production, since that needs signoff from Gregg anyway, keeping it a manual step should not be too onerous. On Google play at least, it's just a few button clicks to promote a build that has come to internal channel automatically from CI to beta and then to production. I'd expect similar for iOS.

[workerbee22]

I'm afraid the iOS/Apple world is often different to Android 😭But lets see what issues we get with approvals on both stores, but we have lots of options with Firebase right now, so we can deal with it whatever happens. I'm in two minds depending on if we get stuck on approvals, but this only changes which tools we use, the approach remains the same.

[workerbee22]

ps. Also assume Apple/iOS = 3 x as much effort ... because it is is always at least this or more.

[greggmiller]

@workerbee22 @maks @lukesleeman

Agree with all of the above. From the WH perspective...

1. Development release Myself and if possible the other WH staff who have been involved in providing opinions on content.

2. Beta release Same as above + 3 or 4 others integral to anaesthetic department management, education and information provision. As we approach a near final V1, there will also likely require sign off from legal and public affairs required to reach V3. It is difficult to get much progress and approval from them prior to a functioning Beta version V1. However, when we have a V1 for Beta release on TestFlight, and everyone contributing on project is in agreement, we can add the anaesthetic department and ICU (the total numbers for this would be ~100-200). Like anything else, there wouldn't be 100% uptake, but this would get it in to the hands of those who it is aimed to benefit.

3. Production release Will require finalisation of steps above which we will all keep chipping away at 😄 👍 I will keep you all in the loop about any major changes or developments.

[workerbee22]

Ok the more detailed implementation of this process has chnaged slightly and summarised as follows:

WHAC19 CI & CD Overview v2.pdf

[workerbee22]

Further to this we have in effect:

Closed Beta (both Android and iOS)

-App Store Connect - for list of invited testers/reviewers. In App Store Connect this is via enrolling iOS testers in as Western Health account 'App Store Connect Users.

-Google Play - Closed Beta

Open Beta (both Android and iOS)

-App Store Connect - External group called 'User Testers' utilising a 'Public Link' where anyone with the link can self enrol in TestFlight and install the app.

• Google Play - Open Beta

Production App Release (both Android and iOS)

Google Play and Apple App Store release.

[workerbee22]

Will keep this issue open until we are in the production app stores.

[workerbee22]

Google Play Beta release re-submited after initial Beta submission/suspension/removal.

Once this is approved, will look to moving 'Alpha' distributions away from Firebase App Distribution to Google Play Internal channel.

[maks]

@workerbee22 I think we can consider the release process agreed on at this stage, despite waiting on Google Play approval so going to close, but feel free to reopen if there are any unresolved issues with this.

[workerbee22]

Still not done, prefer to keep open a little longer.

[workerbee22]

Release process still to be finalised once we're totally off Firebase App Dist and we have released open Betas and a proper production release to both app stores.

[workerbee22]

Fixed the Google Play release notes with PR 258 being uploaded by codemagic into Google Play 👍

Will keep open until we get first released version to both Android and iOS app stores.

[lukesleeman]

Since it seems we will not be releasing to the play store, I'm going to close this one down.