Mobile app deployment at Unibuddy

Unibuddy’s Mobile development, testing, and deployment journey

In this blog, I will walk you through how we have integrated App Center and the collection of practices that enabled our Mobile team to deliver code updates efficiently, promptly, and automatically in our mobile software development journey.

Steps in App Center

Unibuddy Mobile deployment Architecture

Build and Distribution cycle:
Build and distribute from configured branches in App Center

App Center Build Dashboard: This displays branch name and build status. The green checkmark is the status of a successfully run build from each respective branch.

build-*: Merging the changes into any of the build-* branch would create build to perform internal testing.

dev: On merging changes to the build-* branch will, in turn, create and distribute the staging Unibuddy App to a group of collaborators/testers for internal testing. The dev branch is where we get all the changes of the sprint together, and that is where we release to testflight and have a beta build for Android ready for final internal testing before release.

main: Then, once we are ready to release it into production, the changes from dev branch are merged into main branch, and the deployment workflow to release the App to the App store and Play store is triggered from the App center.

Handling Build Configuration for production, stage, and local

1. To handle configurations for each build, we have used the package react-native-config, and multiple env files were maintained env.production, env.development for Production and Staging, respectively.

Some of the environment configurations in Unibuddy

.env.development file

2. In the App center, the build configuration is attached to respective branches via Environment variables.

IMG I: Environment variables of main branch. IMG II: Environment variables of dev branch.

3. And in appcenter-post-clone.sh, while cloning the repo the .env file is replaced with contents of ENV_FILE from Environment Variables in App center build configuration (check IMG I and IMG II).

cat "./$ENV_FILE" > ./.env

eg:
dev ⇒ .env.development
main ⇒ .env.production

4. App versioning is done from appcenter-pre-build.sh.

Update Version and Build Identifier in iOS
Update versionName and versionCode in Android

In the repo, the version of the app is tracked through versionConfig.sh file.

versionConfig.json

This appVersion updated in versionConfig is updated on Android and iOS build via appcenter-pre-build.sh script.

appcenter-pre-build.sh

NEW_VERSION: it is the version defined in versionConfig.json. NEW_BUILD_CODE: Current Time Stamp (eg: 2147483647)

Note: versionCode (Android) is an int. Java's Integer max value is 2147483647. The disadvantage of this approach is that this will only work until 18 Jan 2038, since after that date, this will not be in the range of int. You could, however, take your date/timestamp and modify it in a way that it would never reach this number. For example, you could divide the timestamp by 10.

Automating Codepush Release:

• We rely on github actions to perform App Center Codepush.
• Creation of tag from either main/dev branch from github-UI initiate codepush workflow to Production/Staging app versions.

codepush.yml: github action on creation of tag to perform Codepush

• Here tagName is the version of the App into which we are codepush-ing to:

eg: tagName = v1.2.3 ⇒ This signifies the codepush happened to v1.2.3 version of the app

• App center cli validates the codepush command with API_KEY, which is set up in github Environment secrets for the repo.
• Also we do some extra checking in order to confirm there is no version mismatch.

What Next?

Add E2E testing in App center.

I learned that lessening release time and automating cumbersome release process in mobile is one of the most vital things that we need in the team. Engineers should always strive to maintain confidence on all releases (even on Friday eve 🥳).

The bigger the mobile team thatwe have, the more important all these tools become.