Best practice for setting up an automated build server for iphone apps?

Question

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 n

Answer 1

I realize it has been a while since this thread was last updated, but I have come across a new continous integration (CI) server since then. Or actually its not new, but its integrated support for Mac/IOS builds is new :)

Its the TeamCity product from JetBrains available at http://www.jetbrains.com/teamcity/

We use it successfully at client I work for for building Java projects, but we will also go for a setup for IOS builds as that is becoming a greater part of our product range.

Its fairly easy to setup and can run of any platform, but the buildagent must run a Mac computer.

Hope this helps :)

Answer 2

One new option is Xcode 5 combined with Mac OS X 10.9 (Mavericks) and OS X Server. OS X Server now has an Xcode server component which is good for running automated tests.

It can do:

1. Build (+check for warnings)
2. Analyze (ie. clang static analysis)
3. Run tests on iOS simulator + all connected devices connected to it with USB

For running tests on devices, it beats jenkins/hudson for simplicity and ease of setup by a huge margin. However the Xcode server (as of Xcode 5.1) is completely uncustomisable - if you want to add custom graphing of performance/memory usage/whatever, you can't - for that kind of power, jenkins/Hudson are far better.

Answer 3

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.