Build a Foursquare clone iOS app — Part 3: Continuous Integration
- 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
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 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.
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:
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
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:
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.
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
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.
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:
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.ymlfile in the root of the project to exclude external dependencies from linting. In this file you can also add custom lint rules:
bundlerand add a
Gemfileto your project:
gem install bundler
- Add a
Dangerfileto 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
Dangerbot. 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_TOKENenvironment variable on TravisCI settings page of your repository:
- Instruct TravisCI to run Danger with
bundle exec danger:
- Create a commit in another branch and open a PR to test the integration. You should see something like this:
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.