iOS Continuous Integration Using Travis CI and Fastlane
This post will cover an easy-to-setup approach to CI for iOS apps. The setup uses Travis CI as CI provider, the reason being that Travis CI is cloud-based and has a free-plan for open-source projects - even for building on macOS (usually not the case with other CI providers). So let's not waste time and take our apps to the next level!
Setting up Travis
So I'm just going to quote the initial setup from the Travis CI docs here:
- Go to Travis-ci.com and Sign up with GitHub.
- Accept the Authorization of Travis CI. You’ll be redirected to GitHub.
- Click the green Activate button, and select the repositories you want to use with Travis CI.
Bundler + Gemfile dependencies
We'll be using Bundler so we have a Gemfile specifying all the RubyGem dependencies that we need. That will make it easier when we need to install the dependencies on Travis CI.
If you don't have Bundler installed already on your Mac, do it by running
gem install bundler. If you don't have permissions, you need to have rbenv installed or
sudo it if you're brave.
Navigate to the directory of your project and run
bundle init. That will create a Gemfile for you. Here are the dependencies we need to install, so copy/paste this code into your newly created Gemfile:
source "https://rubygems.org" gem "danger" gem "danger-swiftlint" gem "fastlane" gem "xcode-install"
Now that we've specified the dependencies we need, install them by running
bundle install. This also adds a Gemfile.lock to your project, specifying the versions of the dependencies that were installed.
Travis CI environment variables
We need to provide Travis CI with two access tokens to do its thing. Go to GitHub's Personal Access Token in Settings and generate a new access token. You can name it "travis" if you like. Then you need to go to the environment variables section of your repo in Travis CI. It should be under Settings. You then need to create these two environment variables and copy/paste the access token into them:
That should give Travis CI the access it needs.
Creating .travis.yml with stages/jobs
Now, onto the more interesting stuff. Create a file in the root of your project and name it ".travis.yml". This is where the CI magic happens - here, we will define all the jobs that we want to run. Naturally, depending on your project, this file will differ greatly. So I'll just share how it looks in my app QCards and take it from there:
# environment setup language: swift osx_image: xcode11.1 # caching of dependencies cache: bundler: true directories: - Carthage # run jobs on changes to master only branches: only: - master # prepare dependency managers before_install: - brew update - brew outdated carthage || brew upgrade carthage - gem install bundler -v "$(grep -A 1 "BUNDLED WITH" Gemfile.lock | tail -n 1)" # install dependencies install: - travis_wait carthage bootstrap --platform iOS --cache-builds - bundle install # jobs and stages to run jobs: include: - stage: "Code validation" name: "Code validation" script: - bundle exec danger - stage: "Test" name: "Unit tests" script: - bundle exec fastlane unit_test - stage: "Test" name: "UI tests" script: - bundle exec fastlane ui_test
What you need to take away from this is that we have two stages: "Code validation" and "Test".
- "Code validation" is our first stage which contains a single job that triggers Danger. If all of the jobs in a stage passes, we proceed to the next stage. In this case, we only have one job that needs to pass to proceed.
- Our second stage "Test" contains two jobs that will run in parallel: "Unit tests" and "UI tests". The command
bundle exec fastlane [lane_name]simply triggers a lane in our Fastfile which, in turn, triggers the execution of the tests.
Code validation using Danger + SwiftLint
Danger is one of the dependencies we specified in our Gemfile earlier. It's a great tool to improve our code reviews and simplify pull requests to our project. The Danger docs describe itself like this:
Danger runs during your CI process, and gives teams the chance to automate common code review chores.
These chores could be anything from formatting issues in the code to formalities such as not leaving a description in the pull request. You decide on the rules using the Dangerfile. What happens is that Danger will leave messages in your pull requests when you violate any of the rules. Here's the rules that I use in this Dangerfile and you can expand it with your own rules.
We also specified "danger-swiftlint" in the Gemfile. It's a plugin for Danger that allows us to use SwiftLint in combination with Danger to perform linting and report back if there are any violations. Create a ".swiftlint.yml" file in the root of your project. You can copy/paste the linting rules that I normally use here. Lastly, make sure that you have these two lines in your Dangerfile:
swiftlint.config_file = '.swiftlint.yml' swiftlint.lint_files inline_mode: true
That's the code validation! Now, onto the automated testing.
Testing using Fastlane scan
We are using Fastlane scan to run our tests. So we need to set up Fastlane by running
fastlane init at the root of our project and select: "4. Manual setup - manually set up your project to automate your tasks". That will create a Fastfile inside the newly created fastlane folder.
Now, go ahead and run
fastlane scan init in your project to create a Scanfile inside the fastlane folder. This is a configuration file with all the default parameters we want to set when we run the tests. It could look like this, but you want to check the docs to see what makes sense in your project:
devices(["iPhone 11 Pro"]) reset_simulator(true) clean(true)
In your Fastfile, create one or more lanes where you'll run your tests. In my case, it looks like this:
setup_travis default_platform(:ios) before_all do xcversion(version: "11.1") end platform :ios do desc 'Runs the unit tests in QCardsTests' lane :unit_test do scan(scheme: "QCardsTests") end desc 'Runs the UI tests in QCardsUITests' lane :ui_test do scan(scheme: "QCardsUITests") end end
It goes without saying that you should change the code to match the schemes in your project.
Now you should be all set with the testing. If you've come this far, you should be able to create a pull request with changes to your code and see the CI in action. If everything is successful, you should see a screen like this in Travis CI:
That's it! A good CI setup can make you and your team members lives a whole lot easier. It may even determine if your app makes or breaks it during development. You can find the source code for this exact setup on GitHub.
In the next posts, we'll expand upon this setup so that we can automate code signing and deployments to App Store.
Thanks for following along!
Share this post
You may also like
As an individual app developer, you need to bring attention to your published apps. Companies of top-selling apps agree on how this is executed successfully. They create stunning and professional-looking animated 3D mockups of the apps. I’m here to tell you how you can create these for yourself in a matter of seconds.
Transforming operators in RxSwift serve the purpose of preparing data coming from observables before it reaches the subscribers. Let’s cover this type of operators and look at 3 operators you will be using all the time.
A common frustration with the iOS platform is that resources are accessed using magic strings. In practice, this means you’ll find out if an image, icon, localized string etc. exists at runtime. Either by seeing what you were hoping for or getting a hard crash. Let’s fix this by introducing your new best friend – R.swift.