Build a Foursquare clone iOS app — Part 3: Continuous Integration

Content

• Part 1: Introduction and setup
• Part 2: Location data and managing dependencies
• Part 3: Continuous Integration
• Part 4: Streaming location
• Part 5: Network layer
• Part 6: State management

Introduction

We will use Continuous Integration (CI) in our project to check the quality of our application automatically by each commit we push to the repository. CI could also be used to automate the build and deploy of the application to App Store but this won’t be covered here.

You can always check the Github repository for reference.

Travis CI

Travis will be responsible initially for cloning the latest repository commit, installing its dependencies and then it will try to build and run the tests we have written in the previous post. After running the CI script, it will mark your commit/PR as invalid if the build or the tests fail.

I have chosen Travis CI as a CI platform because I had some experience with in the past. It has some good adoption from the open source community, so it also has a decent support from StackOverflow.

Get started with Travis

First, login at TravisCI page using your Github account and add the repository by flicking the switch in the profile page. Travis is already listening your commits.

Then you need to instruct Travis what you want it to each time you push a commit. These instructions are passed in a .travis.yml configuration file that you need to create in the root folder of your repository.

Here’s how the file would look like initially for our project:

TravisCI instructions file

Tip: for debug purposes you can run the xcodebuild command locally in your local terminal in the root folder of your project without the -quiet flag so you can read the output.

CI and git workflow

I like to use git following the feature branch workflow, because it allows an entire change to be code reviewed and validated in a pull request (PR) before merging in the master branch.

After commiting the .travis.yml config file, all your PRs from now on will show an status of the last TravisCI build for that branch:

Merge your PRs with confidence

The status above means our application compiled successfully, but we can achieve more with TravisCI. In the next step we will use another free tool with TravisCI to also display the code coverage of tests of our application.

Enter Codecov.io

Codecov is a tool used to centralize the code coverage history of your repository. Travis will be configured to upload the code coverage report to Codecov after running the tests described in the previous article.

To enable this feature, first you need to configure your Xcode project to generate the coverage data so you can upload this later: select your scheme and tap “Edit Scheme…”, select “Test” and enable the “Gather coverage data”.

To enable Codecov in your repository, first sign up using your Github account and then add your repository there. Done this, you can already start uploading your coverage data by configuring travis.yml :

From now, apart from building the app, Travis will run your tests and generate a code coverage report that will come in a comment in the PR.

Static analyisis

Codebeat will inspect our codebase for duplication, complexity and much more, helping us to write clean code. The setup is pretty simple, just need sign up and add the desired repository there. Right now, the merge button of Github pull request will be like this:

Think twice before you merge

Danger and Lint

Danger is another CI tool that enforces conventions during code review. In this project we will be using the default configuration plus the SwiftLint validation. To make it work you basically need to:

• Add a .swiftlint.yml file in the root of the project to exclude external dependencies from linting. In this file you can also add custom lint rules:

• Install bundler and add a Gemfile to your project:

gem install bundler

Gemfile for ruby dependencies

bundle install

• Add a Dangerfile to your project. In this file you can define rules that will be used to validate pull requests:

• Create another Github account to serve as your Danger bot. In my case I’ve created one with the username fabiothiroki-bot . In this new account, create a new personal access token containing access to public repositories:

• Add the personal token to the DANGER_GITHUB_API_TOKEN environment variable on TravisCI settings page of your repository:

• Instruct TravisCI to run Danger with bundle exec danger:

Travis with Danger integration

• Create a commit in another branch and open a PR to test the integration. You should see something like this:

Reducing human mistakes

Conclusion

It definitely takes some time to setup your repository on CI tools, but if your project has some complexity, it’s worth because it will save code review time and prevent bugs. And it’s also something you will probably need to do once per application in the beginning of the project.

You will also have your developer experience improved by automating the boring repetitive tasks described in this article.

Bonus: you get nice badges for your repository

Next part: Streaming location