The engineering teams here at Vokal are constantly tweaking and refining our process and tools to ensure that we’re reliably and efficiently producing our best possible work. On the iOS team, this includes ongoing improvement to our continuous build server implementation on Travis.
For about a year now, we’ve been using fastlane to build our apps and run our tests on Travis. The fastlane suite includes a number of individual tools that make life easier for iOS engineers, and we use most of them at Vokal. In this post, I’ll explain what Travis actually does, the benefits this affords us, and how you can implement a similar setup for your project.
About Fastlane & Travis
Fastlane is a collection of tools that work together from the command line to accomplish tasks that iOS engineers normally do from within the Xcode UI. This allows us to automate things like building the app, running the unit tests, signing builds for distribution, and uploading those builds to iTunes Connect and third-party services like HockeyApp. It can even do things like take screenshots of your app (for use on the App Store) and manage push notification certificates.
Travis is a continuous integration server as a service. Every time one of our engineers opens a pull request on a GitHub repo for a client project, a Travis build is started to:
- Build the app
- Run the unit and/or UI tests
- If the tests are successful, upload test coverage report to our CVR server
- Report the results back to GitHub
These builds take a little while to run, but once they finish, we get valuable information right in the pull request:
- If the unit tests fail, a big warning is displayed
- If the test coverage falls below the minimum threshold, a big warning is displayed
- Links to both the Travis build and coverage report for the latest commit in the PR are included
If the build fails, it means we need to fix something: the change in the pull request has introduced an unintended bug that caused a test to fail, or a test needs to be adjusted for changed functionality, or a newly-added test isn’t working correctly yet. Since we run the tests locally before pushing commits to GitHub, this doesn’t happen often.
When a pull request is merged, a similar build is triggered for the latest commit in the master branch:
- The app is built and tested again
- If the tests are successful:
- Upload test coverage report to CVR server
- Build the app again, using distribution signing
- Upload the app to HockeyApp and/or iTunes Connect, for distribution to testers or the App Store
- Bundle commit logs since the last tag and use as the initial release notes
- Tag the latest commit in GitHub with the build number
The Value Add
Even though we sometimes have to wait for builds to finish running on Travis, this process saves us a ton of time over the long run. We always know that our code is adequately covered by passing tests. We don’t have to worry about missing a step or messing up a build when manually creating one for distribution to our internal testers or the App Store. By automating the whole process, we ensure that it’s consistent and reliable.
Try It Yourself
Automating your build process with Travis and fastlane can be a bit fiddly, especially if you’ve never done it before. I mentioned earlier that we’ve been using these tools together for about a year, but what I didn’t mention was that we’ve made a lot of adjustments throughout the course of that year to dial in our configuration and scripts.
Travis has two tiers: paid builds for private repos, and free builds for open-source projects in public repos. The functionality of the two is basically the same, but free builds usually take longer because they go into the open source build backlog. Paid plans include a number of concurrent jobs, so those builds will typically start right away if your account is not already running any builds (and Travis isn’t running at full capacity).
- Login to Travis
- For open-source repos, use travis-ci.org
- For private repos, use travis-ci.com
- Find the project you’re working on
- If it doesn’t appear in the list, click the Sync Account button to have Travis refresh the list of repos from your account
- Click the slider at left to enable Travis builds for it; you won’t see much happen at this point: you still need to configure the repo
Fastlane Setup & Integration
Next, you’ll need some configuration files and scripts. If you used our project template to create your project, then you’re in luck: you’ve already got the files you need. If not, you can still get them from our project template repo. Our engineering documentation site has a page on Fastlane & Travis CI that includes some instructions on retrofitting projects with our fastlane configuration and scripts that run on Travis.
Once you’ve got those files in the root of your project, review these files and set project-specific values where appropriate (for things like the name of the workspace file and shared scheme):
Make sure you have bundler installed, then run:
This will install the gems specified in the Gemfile. Once complete, commit the Gemfile.lock that’s created.
Now you’re ready to test locally by running:
bundle exec fastlane test
- Tell bundler to use the version of fastlane that’s specified in your Gemfile, to:
- Run the test lane that’s specified in fastlane/Fastfile, which will:
- Use scan to build and test your app, using the workspace and scheme specified at the top of the Fastfile, and
- Generate a test coverage report
If everything is setup correctly, you’ll get a success message (or perhaps a test failure message). That means you’re ready to start leveraging Travis to run the build process for you.
Test on Travis
Create a new branch and commit the new files you’ve added, then open a pull request on your repo. Since you enabled builds for the repo in Travis, Travis will trigger a build and run the command specified in .travis.yml (the same command you just tested locally).
There’s a lot more that can be done with both Travis and fastlane, and this post doesn’t even cover everything we use them for. I just wanted to help get you started, so we didn’t cover the setup for match, which handles code signing on merge builds (for upload to HockeyApp and/or iTunes Connect), or uploading build artifacts to S3 for safekeeping.
If you’d like to explore these and other possibilities, we’d love to help you do so. Get in touch and we’ll help automate your build process.