Automating a React-native Mobile Application for Beta Testing

This post focuses on automation and deployment of a react-native application for beta testing from a continuous integration environment.

My workflow includes the following tools

1. Jenkins for triggering the build automation.
2. Docker for containerizing and building,unit testing and deploying.
3. TestFairy for uploading the build for beta testing.

Testfairy is a beta testing platform (TestFairy) where developers and testers can collaborate for mobile testing.

There are many ways of setting up the above workflow. However I would be outlining the approach that I followed, but I would try to highlight on alternative ways for each step to keep the options open for those of you who are reading.

The diagram below highlights the workflow and the flow of the data from the point of extraction from a source repository to deployment.


Usage of Jenkins

Jenkins is responsible for fetching the source from the source repository triggering the react-native build in a containarized fashion.
Uploading the final build to test fairy could have been done via the Jenkins test fairy plugin (

But I didn’t go ahead with this approach since the TestFairy plugin requires the zipAlign tool to be present, which is found with the Android SDK. However in my current setup Jenkins itself is running within a docker container and I didn’t want to clutter it up with additional dependencies like the Android SDK. Also I wanted a way to trigger TestFairy deployments during development time as well. All of the directed us towards the TestFairy Gradle plugin since Gradle was already part of our build system and we use it during development time for the react-native application.

sudo chmod 777 ./android/gradlew
sudo docker rm -f container-client-build || true
sudo docker build -t container/client -f Dockerfile .
sudo docker run -v /home/centos/jenkins/workspace/container-client/DeployToTestFairy/build:/mobile/android/app/build --rm --name container-client-build container/client

Usage of Docker

Docker was used to sandbox and build the react-native application. I made sure the image built for the containers are immutable, so that if the built image is tagged, it has all the required source code packaged so that a build could be repeated. The container did not depend on any external configuration but exposed the build artifact through an external volume mounted to the container.

The docker image I created was based off of

This image sets up the following.

1. Java Open JDK 1.8
2. Android SDK 2.3
3. Gradle 2.4
4. NPM
5. React-native CLI (I know this is overkill! I’m not going to use it for development but based off of it since I couldn’t find anything with the above configuration.)

The Dockerfile is simple and executes a few commands.

FROM lovato/react-native-android
MAINTAINER Lasitha Petthawadu
RUN mkdir /mobile
COPY . /mobile
WORKDIR  /mobile
RUN chmod 775 -R *.*
RUN npm install
RUN  cd /mobile/android && chmod 775 gradlew
WORKDIR /mobile/android
RUN gradle clean
CMD ["gradle", "testfairyRelease","--stacktrace"]

First during build time the image packages the source code, installs the npm dependencies needed for the application.
Once that is done the entry point for the container execution is set to trigger the TestFairy deployment.

I will fill in the Test fairy Gradle configuration in the next section but its quite self explanatory and the TestFairy documentation was quite sufficient enough to get a stab at it from the start.

Gradle Testfairy Plugin

The final piece of the puzzle was to set up the Gradle TestFairy plugin. The Testfairy Gradle plugin is based on the TestFairy Uploader API and it provides all of the configuration and is upto date and inline with it.

The Gradle configuration is quite straightforward. Adding the TestFairy Gradle plugin to the dependencies and applying the plugin in the Build.gradle, gets the plugin included in the build system.

However as I explained before the plugin configuration needs to be added to the android configuration section of the module build.gradle file.

The configuration that could be tweaked is as below.

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"

    defaultConfig {
        applicationId "..."
        minSdkVersion 16
        targetSdkVersion 22
        versionCode 1
        versionName ""
        ndk {
            abiFilters "armeabi-v7a", "x86"


    testfairyConfig {
        apiKey "..."
	testersGroups "dev"
        notify true
        autoUpdate false

The official documentation here would be an updated reflection of the configuration than what is presented in this blog. To get the API key for uploading the builds to test fairy you could login to your Testfairy account and navigate to the Account Preferences and copy the Upload API key


However, one of the gotchas I had was, when I wanted to notify the testers once a build is uploaded. However, even after setting the “notify true” property, the notification mail never reached any of the testers.
Later on, I discovered that the issue was due to not having tester groups and I had to specify “all” as the testerGroups to get the notification mail across. This though documented in the TestFairy Uploader API was quite cryptic and didn’t catch my mind during the first read through of it.

Alternative Approaches

Well, this explains how I approached it and got my builds deployed. However if you want to keep the setup simple you could always use only the Jenkins environment with the TestFairy Jenkins Plugin and all the build tools deployed within the CI environment. But the reasons above made me move ahead with the approach explained here.
There are also other integration methods available you could check then out at the TestFairy API Documentation


One thought on “Automating a React-native Mobile Application for Beta Testing

Add yours

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by

Up ↑

%d bloggers like this: