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.
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 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
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
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 run
app-releasescript in order to update the app version and push a new tag to GitHub.
new-github-release.yml: A workflow that is triggered whenever a new tag is pushed to GitHub. It will create a new GitHub release based on the tag name with the correct changelog.
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 to your app, you need to follow these steps:
Run Build Locally
First, make sure to create an Expo account then create a new organization for your project.
When then name of your organization is ready, you need to update the
EXPO_ACCOUNT_OWNER variable in
env.js file with the name of your organization.
For QA release:
The above command will regenerate the iOS and Android folders based on the
Then run the following command to build the app using EAS:
The above commands will generate the required credentials for the build and store them in EAS servers so that we can use them later to trigger the build from GitHub actions.
For production release:
In case you want to submit the app to the App Store and Google Play, you need to check eas submit configuration and follow the steps from EAS docs.
Setup GitHub Actions
All github workflows are already ready to be used in the starter. You just need to add the required secrets to your GitHub repo:
GH_TOKEN: A Github token with access to your repo.
EXPO_TOKEN: Expo token to authenticate with EAS. You can get generate yours here
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.
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.