App releasing process
Releasing your app to the App Store and Google Play or even to your QA team for real testing is a very important step in the app development process. Internally, we tend to release a new version of the app to our QA team by the end of each sprint(every week or two weeks). This way, we can get feedback from our team and test the app on real devices.
Doing this in a weekly basis requires automating the process as much as possible to gain time and avoid a lot of manual work.
To make this process as easy as possible, we use Github action and Expo EAS to build and release our app to the App Store and Google Play Store.
The Philosophy
The philosophy behind this process is to have a single task that you should trigger to build and distribute the app. This task should be triggered manually by any developer on the team.
The main idea is that we focus on the QA release process and push a new release to the QA team whenever our team pushes a new release to GitHub (at the end of the sprint). Whenever we feel that we are ready to push a new release to the App Store and Google Play, we can trigger a production release manually from the master branch or from the last GitHub release tag that has already been pushed to the QA team.
In conclusion, we have two types of releases:
-
QA release: This release is triggered automatically whenever a new github release is created. This release is used to distribute the app to the QA team for testing.
-
Production release: This release is triggered manually whenever we want to push a new release to the App Store and Google Play and can be build it based on the last GitHub release tag or from the master branch.
The Process
The starter comes with a set of tools and tricks that help make the process as easy as possible.
app-release
npm script
A simple npm script that run np package that helps us to manage the version of the app and push a new tag to GitHub.
If you run pnpm run app-release
, it will ask you to choose the type of release (major, minor, patch). based on the type of release, it will update the version inside package.json
.
As we use the version from package.json as app version inside app-config.ts
, we just need to run the prebuild script to update App version inside the ios
and android
folders. The prebuild script will be executed automatically using a version
script inside package.json
that will handle the task for us. It will also add the changes to the commit that will be pushed to GitHub and create a new tag with the version number.
So technically, we just need to run pnpm run app-release
and it will handle the rest for us. from updating native app version to pushing a new tag to GitHub.
GitHub actions and Expo EAS workflows
The starter comes with a set of GitHub workflows that use EXPO EAS to build and distribute the app to the App Store and Google Play.
-
new-app-version.yml
: A workflow that runapp-release
script in order to update the app version and push a new tag to GitHub. -
eas-build-qa.yml
: A workflow that is triggered whenever a new release is created on GitHub. It will build the app using EXPO EAS and based on the config it will distribute. -
eas-build-prod.yml
: A workflow that is triggered manually whenever we want to push a new release to the App Store and Google Play. It will build the app using EXPO EAS and based on the config it will distribute.
In conclusion, when you want to release a new QA version, manually execute new-app-version.yml
with the correct release type. After successful execution, new-github-release.yml
will be triggered automatically, followed by the automatic execution of eas-build-qa.yml
. This will distribute the app to the QA team.
Setup Release Process to your app
To setup the release process for your app, you need to follow the steps from our EAS instructions file.
Create new release
For QA release, Go to your GitHub repo actions tab and run new-app-version
workflow with the your desired release type.
After successful execution, a new tag will be pushed to master and then new-github-release
workflow will be triggered automatically and create a github release based on the tag name with the correct changelog.
After that, eas-build-qa
workflow will be triggered automatically and build the app using EAS and distribute it to the QA team.
For production release, Go to your GitHub repo actions tab and run eas-build-prod
workflow manually.