Setting up an Automated Build in an iOS environment

by George on Aug.13, 2010, under Coding, Project Management

Disclaimer: I’ll let you in on a secret now, to avoid disappointment later on. By the end of this article you won’t have a fully working automated build The reason is that I was half way through writing up this article using CruiseControl when I started to look at Hudson, which seems like it might be promising. So this week is an introduction to the idea of continuous integration and automated builds and how they can save you time and grief. Next week I’ll aim to have a useful build system up and running along with instructions on how to set it up…

Alex Okafor’s post last week got me thinking that it’s well past time I set up an automated build system, or better yet one that supports continuous integration (feel free to capitalise the ‘c’ and the ‘i’ if you want to turn it into a buzz phrase). Chances are that if you know what I’m talking about, you’re nodding your head in agreement now (and can skip the next section). If not, then read on…

What? Why?

An automated build is a system that can build your software from source to finished product without human intervention. At it’s simplest, this can be an XCode project or a makefile – after all, you don’t compile each file and link them together by hand, do you? The key idea is that we can remove human error from the process, making it more efficient. The ideal is to have a system whereby you can build all versions of your software with a single click (and also score a couple of points on the Joel test).

Consider the following situation. You want a fresh build of the code to show off to your boss, “Reckless” Jim, to keep him off your back. When you wake up, you grab your iPhone 4 (lucky bastard), open Safari and click a link on a web page before you get in the shower (remember to put the iPhone down first). While you’re halfway through your hot water supply (and the Sound of Music soundtrack), the following is happening:

Your ‘build’ machine HAL schedules an automated build.
It grabs the latest code tagged as ‘stable’ from source control.
The code is then built in all configurations (debug/release, simulator/iPhone/iPad).
Unit and functional tests are run on the resulting apps to ensure that nothing is broken.
The built apps are bundled up with a provisioning file, ready for installation on any of your test devices.
The resulting bundles are copied to a shared folder for you to download while scoffing down your Fruit Loops.
An email is sent out to the team notifying them of a successful build, along with details of tests run, how long it took to build and who has committed the most lines of code in the last week.
You grab Reckless as he comes in the door (he’s always late) and put a running build in his hand.

Cool, huh?

Or how about this:

Your team mate “Lazy” Jason checks in a new feature, and heads out (it’s 2pm) so he can go surfing for the day.
Your build system Grumpy detects the change in source control and begins a build.
By now Jason is half way out the door, but he’s paused to (try to) chat up Christine, the new graphic designer who started yesterday.
Meanwhile, Grumpy is building the source code from the development branch in source control.
Uh oh! The build is broken – Jason forgot to check-in AwesomeFeature.mm.
Grumpy send a text alert to you (as build monkey) as well as to Jason who was the person who caused the build to break.
Jason is beginning to have a bad day. Not only has Christine turned down his advances in an unequivocal (and slightly cruel) way, but you catch him before he gets out the door.
Disheartened, Jason heads to his desk to fix the build. Fortunately the solution is fairly obvious and he checkins in a fix within a couple of minutes.
Good news – the new build is fine. The team is notified of a clean build and Jason can leave for the beach knowing the team doesn’t hate him, but that he is now the nominated build monkey until some one else breaks the build.

Neat, eh?

This second example is what’s known as continuous integration – every time you check in new code to source control, the whole build is exercised to make sure nothing’s broken. Why? Often a broken build is a simple 30 second fix at the time, but 2 weeks later it might require hours of sorting through commit logs to see where the problem is.

The solution

CH-47 Chinook.jpg

So, what does it take to set up a system like this? Not as much as you might think. There are some neat tools out there to get you up and running fairly quickly. The problem is that I didn’t have time to try out both of the likely candidates for this week’s deadline. I’ve used CruiseControl before, and Hudson looks promising.

So here’s the goal for next week. I’ll show you how to set up a system that will:

Monitor source control (Mercurial and Subversion in my case), kicking off a build whenever changes are checked in.
We’ll schedule a nightly build as well, just in case anything outside of source control has changed.
We’ll be able to manually kick off a build as needed.
The build will grab all our source code from source control and build it in all relevant configurations – debug, release, simulator, device and so on.
When the build is finished, it’ll notify people of the success / failure.
There’ll be a handy location (web page most likely) where we can monitor / control the whole thing.

And a few nice to haves if I can figure them out:

Automatically update version numbers on our ‘stable’ build with each build.
Bundle up the resulting builds with a provisioning profile and copy them to a shared folder.
Start up automatically under when your build machine is booted.
Paint a unicorn.

More next week!

In the mean time here’s a couple of sample chapters from Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications that covers the basics of setting up CruiseControl.

So, now to decide between Hudson and CruiseControl. If you have any thoughts on either of these systems (or another I haven’t heard of), please let me know in the comments below…

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Share with friends: