Our setup at Basecamp for testing our iOS apps is pretty neat. It (synonymously) involves Xcode’s CI Bots, but that’s easily the most uninteresting part of it. Here’s how we continuously integrate our iPhone and iPad apps at Basecamp and get build results into our Campfire.

Build your bot

This is easily the trickiest part. However, it is pretty boring. Once you’ve followed Apple’s tutorials to setup OSX Server and the Xcode service (which I will skip or lose pretty much everyone reading this for several hours), you just need to head to Product > Create Bot inside of Xcode.

I recommend creating an empty Xcode project first to just make sure everything is working – don’t start with your main iOS codebase. I named it “Placebo”.

We have some specific settings on our bots. Here’s a screenshot for each screen in the bot wizard, since there’s no way to share them outside of the Xcode walled garden. The first screen is the easiest:

Next up are credentials. I highly recommend you do not use the default here. Instead use a read-only deploy keys on your GitHub repo. Usually it puts your own public/private SSH key in there, which is just awful.

For our projects we usually skip the “analyze” action. Checking every 5 minutes for new commits usually enough for us too.

Test with all the simulators you need (on Basecamp for iPhone we skip iPads, for example):

If you’re using Cocoapods, you’ll need a “Before Integration” script to install any pods. Using this gist will help, but you need to install Cocoapods (and Ruby) separately on the server first.

Finally, our secret sauce: Add an “After Integration” hook to send an email notification. We send one for nearly everything that could go wrong (and right!) with the build into Mailgun, because this is the only API that Apple provides for bots. Seriously.

And that’s it. From there you’ll begin the dance of just getting the app to build on your server. Usually a whole litany of problems can happen, but luckily the logs are all captured inside of Xcode so you don’t have to go hunting too far to see what went wrong. Let’s continue on our path to Campfire.

Mailgun it down

Since all we have to work with is email as an API, we have to get creative. Luckily, Mailgun is perfect for this. Once you’ve made an account, you’ll want to make a new Route, which you can do from their web interface. Ours looks like this:

Granted your domain is setup properly and your OSX Server can send mail, when a build is kicked off, it’ll email Mailgun with the result, and then HTTP POST that result to a URL of your choosing.

For us, that URL is inside of our internal app Dash, but this could easily be an app on Heroku, DigitalOcean, or anywhere you’d like. You could even skip this part entirely and use Zapier’s email app to accept the email, which might be a lot easier too. Let me know if that works out better for you!

Dash to the finish

We need to notify Campfire about the build passing. Or failing. Hopefully passing. Here’s a snippet from the Rails controller that handles it, and will require some translation on your part for your needs:

This controller action does a few things:

  1. Determines if the build has passed or failed based on the subject line of the email
  2. Parses the email body HTML for a link to the build output
  3. Spits the result of the build into Campfire

Ironically, I did not test this controller, or extract logic to a model, or anything like that.

Can we just have an API please?

The prize has arrived: Your iOS app has been built on an external server. It’s sent an email to Mailgun, which webhooked its parsed contents to another machine, and then you’ve translated all of that into something actionable, real, and tangible:

All of that just for a link in Campfire. Pretty boring.

Thanks to Zach and Jeremy for their feedback.