As Ash said earlier we like using Continuous Integration. Today I spent a large amount of time migrating us to use the new CocoaPods caching system in Travis CI. To make up for my lost time I'm passing on what I've learned and also showing how we do CI at Artsy with Objective-C apps. If you're interested in how we do it in Swift, you can just check Eidolon.
First and foremost, this only works if you are paying for Travis CI.
Travis CI recently merged in support for Caching of CocoaPods - this is great! By using this, we've reduced our build times from an average of about 10 minutes, to about 7 minutes. It works by using your Podfile.lock as a key to cache your Pods directory, if the lock hasn't changed then there's no need to update the Cache and so pod install is not called on your project. This caused me an issue as the [Project].xcworkspace file that CocoaPods generates was not in source control, and the app wouldn't build. Useful note, if you're using development pods in your build you probably shouldn't use this as your Pods directory can get out of sync with the cached version.
We use a Makefile to separate the tasks required to build, test and deploy an app. The general structure of our Makefile is:
A collection of constants that get resued by different make tasks.
Separate commands necessary for running Xcode projects from the terminal.
Commands that manipulate your project state, or maintainance commands.
Commands to get your app ready for the App Store, or Hockey.
If you don't know the syntax for Make, essentially if it's on the same line you're either setting constants or calling other make commands. If it's on a separate line then you are running a shell command.
That gives you a sense of the commands that you can run from the terminal in our projects, next we need to look at the .travis.yml file.
language:objective-ccache: - bundler
env: - UPLOAD_IOS_SNAPSHOT_BUCKET_NAME=eigen-ci UPLOAD_IOS_SNAPSHOT_BUCKET_PR...
before_install: - 'echo ''gem: --no-ri --no-rdoc'' > ~/.gemrc' - cp .netrc ~
- chmod 600 .netrc
- pod repo add artsy https://github.com/artsy/Specs.git
before_script: - gem install second_curtain
- make ci
script: - make test - make lint
This is nice and simple. It was built to use multiple travis build steps. This makes the CI output a lot more readable as an end user. Travis will by default collapse the shell output for different build stages leaving only the script stage defaulting to being exposed. Here is an example of what you see on a failing test:
We use a gem with a binary in second_curtain, and this came with bundler caching issues in Travis. The solution was to ignore bundler and run gem install second_curtain each time. To increase the speed we also ensured that documentation is not being generated. If you are interested in what's going on with the .netrc, read my blog post on Artsy's first Closed Source Pod.
We will continue pushing the state of the art in iOS deployment, in building our own tools and using everything available to increase developer happiness. If you're into this we're always looking to hire people with a good open source track record or street smarts. Here's the jobs page.