Using Fastlane and TravisCI to automate our mobile releases

Although we don’t have a specific team responsible to manage and deploy our app releases, we used to concentrate the responsibility for uploading a new version in a single person: me! That sounds good when your company and teams trust you to do such an important thing. But you know what sounds better? Having this job automated so you can focus on cooler things! ;)

The content of this post is how we provide answers for the questions below without having to ask a human:

• When a new version for TestFlight will be uploaded?
• When does the next release goes live?
• When does the next build can be tested?
• What are the features of this release?
• What is the version name of the next release?
• What is the percentage of users in the current staged rollout?

If you’re reading this article, I believe you may have read thousands of posts about how to build apps on TravisCI/Circle-CI, and send it to TestFlight and Play Store. Yes, we do this on Gympass, however, this is not the focus of this post. Actually, when you have up to five teams working on the same repository and waiting for the same build to go live, you’ll need a little bit more than that.

One year after our first release for Gympass App, we've grown from 3 mobile developers to 14, from a single team working with the mobile app to 7. One year ago, it was ok to release a new version any time we needed, cause there was only one stakeholder to support it, and any bug that could happen used to affect only one team. Nowadays this scenario is totally different since we need to support the entire application in all of our features. We went from “we can send a new version anytime we finish a feature” mindset to “our feature will be released this week depending on when I finish it.”

Now, let’s stop talking about the past and show how Gympass Mobile App Release Train works ;)

Let’s start by coding a new feature and submit a Pull Request on Github (assuming that you’re familiar with the most famous codebase management tool in the world). Of course, your feature has been manually tested and automated tests have been written. Yet, it can be much more accurate if you let TravisCI run all unit and end-to-end tests (E2E) and build Android and iOS projects to guarantee that all the features (and not only those from your team) are ok.

We also require at least 3 approvals on code review so we could improve ourselves (and our codebase) before merging anything.

As we work with React Native, the majority of our unit tests runs in the first job. For Android and iOS, we build the apps (any problem with external libs and dependencies are get here) and run end-to-end tests with the simulator. We’re currently using Jest and Detox as test suites.

So, now that we’ve got our coworkers approvals and our test suites have run fine, we can merge our Pull Request into the master branch.

If you’re a developer, you may have already had an issue when merging something with other developers, right? Something like, after all the merges, finding a bug that was not in the branches previously.

The quickest way to find this bug is to have a build for every new feature that goes to the master branch. Furthermore, any feature that is done generates a release candidate version. So, for every merge into master, a new git tag is generated and will trigger a new build for Apple (TestFlight) and Android (Play Store).

“tag-generate” is one of our stages on TravisCI running just for merges on master branch. It’s responsible to get a list of our previous versions and calculates what should be the next build name and number (example: 3.23.0 build 257), so developers and product managers don’t need to worry about finding a name based on the bug fixes and features that are going live.

“deploy” is our last stage on TravisCI pipeline. It builds both platforms and send them to the stores. Based on each branch we merge, we are able to build a Changelog with all the features we have since the last version released to production. We use Fastlane to get all those informations from stores, such as the current production version, the last version sent to TestFlight, our commits between two tags, and so on.

In the end, when successful, this beautiful message for a channel on slack is sent ;)

It goes already tagging the stakeholders responsible for validating it’s own features. It’s already split by team 😍

Most of that works and automation have become possible since we’ve adopted several standard practices across the teams, such as as “Conventional Commits” commit pattern, and branch naming.

So, who presses the button that releases it to production?

We alternate between teams: a pair composed of a Teach Lead and a Product Manager monitor crashes and errors of the version and publish builds to beta and production. And this is updated in a kanban board visible to all the company.

We do like to test a version with Beta Testers for 2/3 days before it goes to production so we anticipate those crashes that no one ever experience before launching in production. No surprise also that we may accelerate Android Phased Release sometimes.

We usually do the same rollout as App Store recommends, for both platforms. If you're not familiar with Phased Release, this article gives a quick explanation about it

It might be important to say that we haven’t solved all those problems at once, neither those problems have come all in once. Automating a pipeline is probably an endless job, and also addicting. Fastlane and TravisCI have saved us lot’s of hours and choices that we shouldn’t take.

Improving our CI and CD gave our developers skills to focus on new features and fixes. What I mean is that they don’t need to worry about git tagging, testing all the app every time they code a line, downloading certificates, profiles, signing the build, uploading this build, asking God which version name they should choose, slacking 7 teams that they uploaded a new build, reading all the commits to generate a changelog or any other boring stuff like that! Nowadays our teams generate up to 50 versions (each platform) in a month and 5 versions to production.

Well, after all that work across 2019, I was asked about the “Continuous Delivery for Mobile with Fastlane” book, by Doron Katz (available on O’Reilly). While reading its “Table of Contents”, I’ve realized that from 16 actions that are taught, we’ve already done 15. The one that we haven’t, doesn’t fit our behaviors ;) . So, yes, it’s a great book to get to know a little bit more about automating your mobile continuous integration/delivery. We recommend it 👍 !

Hey, don't forget to clap your hands if any of this info has helped you 😄 .