Homebrew, Ruby, and Gems

This article assumes you’ve read the main article already. As well as the provisioning a Mac article.

By now, you have Mac OS X all setup and ready to go. You’ve got Xcode and all your simulators — now it’s time to get all those nice things that people are gonna want. Most of these come in the form of gems and brew packages. Now, let’s be very clear, using system Ruby is a terrible idea. It requires sudo to write into the namespace and will immediately cause you pain when you try to use the gems.

In this article, I’ll show you how to automate Homebrew installation, use Rbenv to install Ruby automatically and manage multiple versions, and list a few awesome gems that you probably should look into.

Homebrew

Homebrew is the goto package manager for Mac OS X systems. It allows you to install everything from MySQL to Ruby. It is an essential for any CI system running Mac.

Luckily, it’s really easy to install. The : | pipes the colon into the prompt and will automate the entire installation.

: | ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Ruby Installation using Rbenv

A number of useful tools for iOS are built as Ruby Gems. While Mac comes with a Ruby version, it is outdated and integrated with the system in such a way that permissions with Ruby Gems are an issue. It is easier and recommended in the Ruby community to install Ruby yourself and not use system Ruby. Rbenv is a good way to install Ruby easily on a Mac and luckily Homebrew makes Rbenv installation very easy.

To install Rbenv, start with the follow command:

brew install rbenv

Once that is complete, you can install a custom Ruby version.

eval "$(rbenv init -)"
rbenv install — skip-existing 2.2.3
rbenv rehash
rbenv global 2.2.3

In your environment for the CI system, I recommend also putting the following. For Buildkite users, this would be the environment hook.

eval "$(rbenv init -)"
rbenv local 2.2.3

Gems you’ll want

Bundler is useful to install gems from a Gemfile. At some point in your CI’s lifespan, someone will probably look to install gems specific to their project (specific code coverage tools, Cocoapods, Carthage, etc.) To ensure they can do this, install bundler with “gem install bundler”.

XCPretty

Have you ever run Xcode on the command line? It pretty much throws up a significant amount of output that makes compilation and test logs very difficult to digest. This is where XCPretty helps us out. It makes Xcode output readable. Look at it here.

If you’re using Buildkite, take a look at xcpretty-buildkite-formatter. This takes Facebook snapshot failures and inlines the images.

Fastlane

Fastlane tools are a suite of tools developed to fill a gap in the mobile CI pipeline. They are a godsend. We’ve had the authors of Cocoapods and some Apple employees themselves recommend their use to us.

A quick overview of what it includes (as of April 10th, 2016):

• deliver: Upload screenshots, metadata, and your app to the App Store
• snapshot: Automate taking localized screenshots of your iOS app on every device
• frameit: Quickly put your screenshots into the right device frames
• pem: Automatically generate and renew your push notification profiles
• sigh: Because you would rather spend your time building stuff than fighting provisioning
• produce: Create new iOS apps on iTunes Connect and Dev Portal using the command line
• cert: Automatically create and maintain iOS code signing certificates
• spaceship: Ruby library to access the Apple Dev Center and iTunes Connect
• pilot: The best way to manage your TestFlight testers and builds from your terminal
• boarding: The easiest way to invite your TestFlight beta testers
• gym: Building your iOS apps has never been easier
• match: Easily sync your certificates and profiles across your team using git

Looking through this list, there are a few new ones missing — notably supply for Android, but that doesn’t affect iOS.

Seriously, the best part about Fastlane is that everything is defined in Fastfiles. You can then import these Fastfiles into each other. This means that you could define some default steps that happen for all your tests and have all the projects in your Org share the same test structure. This would mean that your developers can focus on developing and you focus on one set of tests.

Well, we just finished the main setup for iOS! Your compute setup for iOS and Xcode should be ready. We’ll be going over the host system using Packer, VMWare and ESXi in the future.

For now, if you have any questions or suggestions, share them with me in the comments.