Best practice for setting up an automated build server for iphone apps?
I'm looking to setup an automated nightly build server for our iphone apps, and looking for advice on what works and what doesn't.
Basically, something that at least nightly runs all the unit tests and publishes a new adhoc build to our internal website.
All the developers use laptops (which'll be off overnight), so I'm considering getting a dedicated Mac Mini to do this.
I'm not sure if I should get standard Mac OS X or the server edition.
At least for the first attempt, I'm considering just using a simple shell script run from a crontab to do the actual work. In the future a full continuous integration server (hudson etc) would be good.
I've already found a few articles through searching, though they're quite brief:
http://nachbaur.com/blog/how-to-automate-your-iphone-app-builds-with-hudson
http://blog.jeffreyfredrick.com/2008/11/27/continuous-integration-for-iphonexcode-projects/
and also this stackoverflow question has some useful software info (though it's two years old now):
Continuous Integration for Xcode projects?
Any guidance people can give on how they've setup a build server and any potential issues would be greatly appreciated.
Thanks!
Joseph
Answer
Hudson (or its fork Jenkins) is really not hard to set up; it's what we use internally. We don't just run iphone builds from it -- in fact, there's only only one lone mac mini set up for iphone builds, and it's a relatively recent addition. We've had a half-dozen other slaves on it for other different platforms for some time.
You can play with it through the "Test Drive" link on the Meet Hudson page to get a feel for how easy it is to set up. (This is one of the things that sold me on it; it was really easy to get started with, but still configurable, extensible, and powerful enough to keep us expanding over the last few years. It replaced a really kludgy pile of hand-rolled scripts and programs that, despite being the author of, I was very happy to see laid to rest.)
We have the hudson backend running on a beefy Mac OSX server, but there's no reason you couldn't run it pretty much anywhere (linux, windows, mac).
As for configuring it for building -- it's about 6 lines of shell script in the project configuration, mostly calling xcodebuild and passing it -project and -configuration arguments.
Example:
cd ${WORKSPACE}/Engineering/
set -e
set -v
xcodebuild -project foo.xcodeproj -alltargets -configuration Distribution clean
xcodebuild -project foo.xcodeproj -alltargets -configuration Release clean
xcodebuild -project foo.xcodeproj -alltargets -configuration Debug clean
xcodebuild -project foo.xcodeproj -alltargets -configuration Distribution
xcodebuild -project foo.xcodeproj -alltargets -configuration Release
xcodebuild -project foo.xcodeproj -alltargets -configuration Debug
We haven't set up the slave to run as a service yet -- this is on the TODO list. For now we just launch it via JNLP whenever we reboot the mini it's on.
Repository is SVN, and the hudson master takes care of remembering the https auth info for us.
We actively use the Email-ext plugin, and have a build timeout plugin and an audit trail plugin since there are a lot of other people using the system and some of the builds are not well-behaved. We've experimented briefly with the Warnings plugin and Static Code Analysis plugins as well, need to get those used on more projects (we usually have warnings as errors in builds, but we do use PC-Lint and other tools on some projects; having output aggregated and tracked here is very nice). Finally the all-important Chuck Norris and Emotional Hudson plugins.
We're currently not running unit tests (shame!) on any of the iphone builds, and we just use the ordinary "Archive the Artifacts" functionality built into hudson for storing builds. These can be accessed via authorized users via the hudson web interface. I've no doubt that it would not be hard for you to run your unit tests within the framework.
</fanboy>
Our only real issues have had to do with AFP and SMB on the mac mini -- nothing to do with hudson at all, more just our internal network infrastructure. And the mini is a bit slow for my tastes -- we usually run pretty beefy build slaves on the theory that quick autobuild turnaround is a good thing. The mini may be gifted an SSD for this reason at some point.