I’ve been a really strong supporter of the fastlane toolset. I think it fixes a lot of common developer problems, in a space that Apple doesn’t really touch. The command line.

We’ve added hints of fastlane to our apps at different rates, Eidolon uses fastlane for everything but Eigen/Energy/Emergence have been pretty slow on the uptake, though they have more complicated setups, being App Store apps.

When Felix announced match this week, I felt like he tackled a problem we face in our small dev team. I integrated this, only to find that it could also fix my problems with deployment. The rest of this post goes into the “how I did this.” You can also cheat and look at the commits directly.

First up, a TLDR for match. match is a tool that keeps all of your code-signing setup in a private git repo. We currently keep them in a shared 1Password vault. By switching to using a private git repo we can can use our existing GitHub authentication for CI to provide access to the certificates for signing on circle.

We use a Makefile, I know that fastlane provides an awesome tool in the form of fastlane lanes - but we’re pretty happy with a Makefile, they’re the simplest tool that does what we need.

I wanted to lower the barrier for us shipping betas, so I opted to add another build step in the CI process. This step checks what branch is it, and if it’s the beta branch, grab the certs, then deploy.

	if [ "$(LOCAL_BRANCH)" == "beta" ]; then make certs; make ipa; make distribute; fi

make certs is really simple, it runs: bundle exec match appstore --readonly which and pulls metadata from a Matchfile. This means we can sign app store builds on CI.

If you don’t know what the bundle exec prefix is, I’d recommend reading my guide on the CocoaPods website for Gemfiles.

The next step is generating an ipa, we do this with gym via make ipa which looks like this:

ipa: set_git_properties change_version_to_date
	bundle exec gym

It executes some make tasks to ensure we know what git commit each build is, and we use the date to provide a faux-semver for apps.

Gym will build our app, according to our Gymfile. Nothing too surprising in there. It will output an ipa and a dsym that make distribute can handle.

make distribute is a pretty easy one, we generate a CHANGELOG via Ruby, then run the command bundle exec pilot upload -i build/Artsy.ipa, it will ship it to iTunes Connect after configuration from the Appfile. This is great, but it goes one better. It will, by default, run a synchronous check for whether the App has finished processing.

</div></div><div class='meta-container'><header> </header></div><div class='date-container'> </div><div class='content-container'><div class='entry-content'>

This is awesome. I’d like to add a Slack message to tell us that it’s shipped too, which would be much easier if we used a Fastfile. We’ve not entirely moved all of our apps to TestFlight, this is our first experiment in the space, we’ve been really happy with Hockey, and still are. However, without trying new things we’ll never be able to know what we should consider internal best practices.

Categories: ci, devops, ios, mobile