Building React Native Projects with Native Code: Part 5

Exploring the release branch workflow.

This article is part of a series starting with Building React Native Projects with Native Code: Part 1.

note: While we took a sidebar into the Nevercode continuous integration service, we will continue to focus on Travis CI through the remainder of the series.

Release Branch Workflow

We start to prepare for an application release by creating a new release branch from develop-native. Unlike the workflow around the develop and develop-native branches, we want to generate and distribute (to a larger audience) new versions of the application each time we merge into release.

While not shown in the above diagram, we anticipate that we will need to apply hot-fixes to the release branch through the normal feature / pull-request process (including building review applications).

As hot-fix changes are made to the release branch we will need to merge those changes back to the develop-native (native changes) and to both develop-native and develop (JavaScript changes). These merges can happen after each hot-fix or can be held until the release is complete (really a timing decision).

Release (Alpha) Distribution

We will use the no-cost HockeyApp service to manage the distribution of the application (builds off merges into the release branch).

To get started with HockeyApp, we create a new app, e.g.:

• Platform: Android
• Release Types: alpha
• Title: React Native Scaffold
• Package name: com.larkintuckerllc.reactnativescaffold
• Retention: 90 days

Once created we can invite alpha testers to automatically receive new versions of the alpha build (from merges into release).

In order to integrate HockeyApp with our Travis CI build process, we need to create an API token (Account Settings > API Tokens). As with other secrets, we store these tokens as environment variables in our Travis CI repository, e.g., react-native-scaffold, settings.

Refactoring the Travis CI Configuration (All Workflows)

We are going to completely refactor the Travis CI configuration for a number of reasons:

• When writing the previous configuration, I forgot that Travis CI will run all of the script commands (unlike the other phases) even if one fails
• We have a number of build configurations (Expo only vs. Expo and native builds) and distributions (AWS vs. HockeyApp). These configurations share a lot of commonality (we want to minimize duplication)

The final matrix of build configurations are:

note: There are some extra manual steps required for merges into master (will explore later).

The first Travis CI configuration is done from the website (because we are now building on both merges (push) and pull requests.

The other Travis CI configuration is the configuration file (shared across all the branches):

.travis.yml

Observations:

• We have two jobs to distinguish between those builds that require Node.js (Expo) vs. those that require both Android and Node.js (Expo)
• Outside of the script phase, the implementation is the same as earlier
• In each job, the script phase is now a singular command
• There are two supporting shell scripts: expo.sh and android.sh

expo.sh

android.sh

Observations:

• This script has two supporting scripts: android-aws.js and android-ha.sh

android-aws.js

Observations:

• This is the same script from earlier; just renamed

android-ha.sh

Observation:

• This script makes use of the HOCKEY_APP_TOKEN environment variable that we configured at the top of this article
• HockeyApp has a simple API that we can simply post using curl

Next Steps

In the next article, Building React Native Projects with Native Code: Part 6 , we explore the master branch workflow.