Tech Talks: Deploying a React Native App with Azure DevOps

As part of our engineering team's Tech Talks blog series Phlo's Principal Engineer, Jamie MacDonald, describes setting up deployment pipelines for our new React Native app.

Extending our Azure DevOps Pipelines

We have recently launched our React Native (RN) app into both the Google Play Store (Android) and the iOS App Store. To streamline our releases, and to ensure we have a safe and repeatable release process, we have extended our existing suite of Azure DevOps pipelines.

While the RN app is a single codebase, we needed to build individual pipelines to target the respective app stores. With the Android launch coming first, the Google Play Store was the obvious place to start.

Android

Before reaching a production-ready state and setting up the new pipelines we had a set process to build and deploy the Android app from our own machines. This manual process acted as the blueprint for building out our new pipelines.

‍

‍

Our Android deployment pipeline can be split into four sections:

• Credentials: To sign the app and ensure it is associated with our Google Play Account, we download our Android Keystore file and create a fastlane credentials file which allows fastlane to upload our build to the Google Play Store.
• Environment: To ensure our deployments are flexible we create a Gradle Properties file and a .env file, this allows us to point our app builds at a variety of environments and specify different credentials to allow us to use both testing and production accounts.
• Preparation: Our build from a previous stage in our pipeline is unzipped, we then install Ruby so we can install our gems which we use to generate the app bundle. We also send our source maps to Sentry so that we can accurately track any issues that occur when the build is released.
• Deployment: With everything we need now in place the final step is to run our fastlane command and specify which of our lanes we want to use. The app gets bundled and sent to our specified Google Play Store Track.

‍

iOS

With the Android app able to be built and deployed to the Google Play Store, we moved on to deploying to the iOS App Store. To do this we make use of the built-in Xcode tasks available on Azure DevOps.

‍

‍

Deployment of our iOS app can also be split into the same four sections:

• Credentials: For deploying to the iOS App Store we need to have our Signing Certificate and Provisioning Profile, we install these so they can be used to sign and build our app.
• Environment: We again use a .env file for our iOS build. In addition to this, we also create an entitlements file which is used to specify which URLs are available to universal link into the app, as well as specifying our Apple Pay details.
• Preparation: Again we unzip our build and then perform apod install so that all our CocoaPod dependencies are up to date.
• Deployment: Now we are ready to archive our app, we use the Azure Xcode build task to do this and then use the Apple App Store task to publish our build to Test Flight.

The final step in our iOS pipeline is sending a slack message to a dedicated RN Testing channel, this lets us know the build is complete and ready to test!

‍

Impact

After making these changes, we now have full confidence that we were always deploying the latest and greatest version of the app. It has moved us from a complicated multi-step manual process, to simply needing to press one button. The use of .env files means we can build our app for any of our testing or production environments and we also no longer need to have secure credentials saved on our local machines - these can all be stored safely in the Azure Secure File Store.

These improvements are a huge time saver and allow engineers to focus on solving the next interesting problem rather than waiting for builds and deployments to complete.

Next Steps

The current deployment process unfortunately still involves some manual work due to both app stores requiring unique build numbers for each deployment. Currently, this involves either manually updating the numbers before we deploy or running a script that updates them for us.

The next step in our deployment pipelines will be making this an entirely automated process.

‍

We’re always looking for talented people to join Phlo. Find out more about our open positions in engineering and help lead the future of digital pharmacy.

‍