Best practice for creating an automated build server for iphone applications?

I want to set up an automated nightly build server for our iphone apps and look for tips on what works and what doesn't.

Basically, something that, at least at night, runs all unit tests and publishes a new adhoc assembly on our internal website.

All developers use laptops (which will be turned off in one night), so I'm considering getting a dedicated Mac Mini for this.

I'm not sure if I should get a standard Mac OS X or server version.

At least for the first attempt, I am considering using a simple shell script executed from crontab to do the actual work. In the future, a good continuous integration server (hudson, etc.) will be good.

I have already found several articles through a search, although they are quite short:

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 question using stackoverflow has some useful software information (although it's been two years already):

Continuous integration for Xcode projects?

Any people who can give instructions on how they set up the build server, and any potential problems, will be very grateful.

Thank!

Joseph

+43
objective-c iphone build-automation ipad automated-tests
01 Oct 2018-10-10T00:
source share
3 answers

Hudson (or his Jenkins plug) is really not hard to set up; this is what we use domestically. We don’t just run iphone builds from it - in fact, there is only one single mac mini to build iphone, and this is a relatively recent addition. For some time, we had half a dozen other slaves on other platforms.

You can play with him through the Test Drive link on the Meet Hudson page to see how easy it is to set up. (This is one of the things that sold me that it was very easy to get started with, but still customizable, extensible and powerful enough for us to expand over the past few years. It replaced a really curly bunch of hand-screened scripts and programs that , despite the fact that I am an author, I was very glad to see that I was laid to rest.)

We have a hudson backend running on a hard Mac OSX server, but there is no reason why you couldn’t run it almost anywhere (linux, windows, mac).

As for its setup for building, this is about 6 lines of the script shell in the project configuration, which basically calls xcodebuild and passes the arguments -project and -configuration .

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 have not yet configured the slave to display the service β€” this is on the TODO list. For now, we just run it through JNLP when we reload the mini-minimap.

The repository is SVN, and the hudson wizard takes care of remembering the https auth information for us.

We are actively using the Email-ext plugin, and you have the build timeout plugin and the control trail plugin, as there are many other people using the system, and some of them do not behave very well. We experimented briefly with the Warnings plugin and Static code. Analysis plugins should also get the ones used for more projects (usually we have warnings like build errors, but we use PC-Lint and other tools for some projects; data output is aggregated and tracked here very well). Finally, all the important Chuck Norris and Emotional Hudson plugins.

We do not currently run unit tests (shame!) On any of the collections of iphone, and we just use the usual "Archive artifacts" functions built into hudson to store assemblies. Access to them is possible through authorized users through the hudson web interface. I have no doubt that it will not be difficult for you to run unit tests within the framework.

</Fanboy>

Our only real problems were with AFP and SMB on the Mac mini - nothing to do with the hudson at all, it's just our internal network infrastructure. And the mini is a little slower for my tastes - we usually run rather muscular slave builders according to the theory that a quick turn of a car object is good. For this reason, the mini can be donated to the SSD at some point.

+14
03 Oct '10 at 2:08
source share

I understand that some time has passed since this thread was last updated, but since then I have come across a new Continuous Integration (CI) server. Or it’s not really new, but its built-in support for Mac / IOS builds is new :)

His JetCrains TeamCity product is available at http://www.jetbrains.com/teamcity/

We successfully use it for the client with whom I work to create Java projects, but we will also come up with customization for IOS assemblies, as this is becoming a large part of our range.

It is fairly easy to configure and run on any platform, but buildagent should run a Mac.

Hope this helps :)

+6
Sep 17 '12 at 8:26
source share

One of the new options is Xcode 5 in conjunction with Mac OS X 10.9 (Mavericks) and OS X Server. OS X Server now has the Xcode server component, which is good for running automated tests.

He can do:

  • Assembly (+ warning check)
  • Analysis (i.e. static clan analysis)
  • Run tests on iOS simulator + all devices connected to it via USB

To run tests on devices, it surpasses jenkins / hudson for simplicity and ease of setup with a huge margin. However, the Xcode server (like Xcode 5.1) is completely incompatible - if you want to add custom graphics for performance / memory usage / whatever, you cannot - for such power jenkins / Hudson is much better.

0
Feb 04 '14 at 12:25
source share



All Articles