Deploying to Play Store
The variants of the app have slightly different ways they get deployed to the Store.
- The Sandbox app is automatically deployed to the Play Store, every night at 10pm.
- We do this using Bitrise.io, the CI service.
- There is a "Scheduled Build" that runs every night at 10pm, which runs the
deploy-sandbox-to-play-storeworkflow on the
- No other manual intervention is required.
Scheduled Build that deploys the Sandbox app daily
Our releases happens at regular intervals. For now, this interval is one (sometimes two) week, and Monday is release day.
Demo app being deployed from specific release branches.
- 2.The CHANGELOG.md file must be updated on this release branch: rename the "Next release" section to "On Demo" to denote that the changes of that section are live on the Demo app.
- 4.Push the newly created release branch to the repository. This will automatically trigger Bitrise to run the unit and integration tests build.
- 1.Wait for this build to finish before you move to the next step!
- 5.The Demo app is built from this branch and released to Simple Demo on the Play Store. There is a workflow on Bitrise to do this:
deploy-demo-to-play-store. Run this workflow on the newly created release branch -- everything else happens automatically.
- 1.If you run the deploy workflow before the tests build finishes, you will never know if something is broken in the release build.
- 6.Post the details of this release to the
#releasesSlack channel to inform the rest of the organisation.
- 2.Inform the UI test engineer(s) to run all UI (Appium) tests on this build.
- 3.Link the Bitrise build that ran the unit and integration tests; it also generates an APK pointing to the QA server that the UI test engineer(s) use to run Appium tests.
- If someone discovers a problem in the Demo release, it must be fixed and merged into
master, and then cherry-picked into the release branch.
- Only a few categories of issues are eligible for cherry-picking: bug fixes and language/text changes. All other types of issues will have to wait till the next release goes out.
- Whenever a commit is cherry-picked from
masteronto the release branch, it should be done with the
-xflag to record the SHA1 hash of the original commit on
$ git cherry-pick -x a986fb4
$ git show
Author: Ajay Kumar <[email protected]>
Date: Fri Mar 22 19:42:07 2019 +0530
Show keyboard automatically when update phone dialog is shown
(cherry picked from commit a986fb4)
- Push the updated release branch, and let Bitrise finish running all the tests.
- If all tests pass, the deploy the updated release branch to Demo again, using the same
- The branch that has been on Demo since the last release day is assumed to be ready for publishing to Production.
- Bitrise has a workflow for this:
- The release must be created on the Google Play Console manually.
- Go to the Simple (org.simple.clinic) listing on the Console
- Open Release Management, and then App Releases
- Click on Manage on the "Production Track"
- Click on Create Release to create a new release draft
- Click on Add From Library, which will open the APK Library, where you will find the APK that Bitrise has just created and pushed
- Copy only the fixes and features (exclude internal changes) from release notes from the CHANGELOG.md file
- Publish the release to 25% of users on Monday
- If everything goes alright, release to 100% of users on Thursday
- Post the details of this release to the
#releasesSlack channel to inform the rest of the organisation