在使用Hudson与之前的项目持续集成之后，我想为我正在进行的iPhone项目设置一个持续集成服务器。在做了一些研究后，看起来没有专门为Xcode设计的CI引擎，但是一个人已经取得了成功using Cruise Control combined with the xcodebuild CLI tool。这里有人试过吗？是否有任何CI引擎与Xcode项目配合良好？
我可能会试试Cruise Control。我会用我的发现发表一个答案。
答案 0 :(得分：37)
我在xcodebuild的mac上成功使用了Hudson。随着3.0 iPhone sdk的发布，您可以控制要针对项目构建的目标，配置和sdk。
就像在hudson中创建构建步骤并告诉xcodebuild构建项目一样简单：
xcodebuild -target "myAppAppStore" -configuration "DistributionAppStore" -sdk iphoneos2.1
前期工作为我带来了回报，因为我的构建工作没有任何额外的想法。如果有人有兴趣，我已经在我的博客上写了详细的描述。
答案 1 :(得分：13)
恢复此线程。我没有找到一个令人满意的解决方案，在构建服务器上通过单元测试获得自动XCode构建，因此我做了一些调查和编码。结果是this blog post解释全部和this Ruby script将OCUnit输出从xcodebuild转换为JUnit用于测试报告的XML格式。我选择的构建服务器是Hudson。
2012年3月2日更新：我已将此更新为使用一些自定义shell脚本进行构建和运行。可用here。它不仅适用于持续集成，还适用于您自己机器上的命令行构建。
答案 2 :(得分：9)
Adium非常有效地使用buildbot和Xcode。我们写了一个简单的makefile，用正确的目标和配置调用xcodebuild，但我很确定这是可选的。
答案 3 :(得分：9)
Apple刚刚发布（2013年6月10日）OSX Mavericks（OS X 10.9）一个新的持续集成平台，这是我之前见过的最集成的持续集成解决方案。 它可以从developer.apple.com获得，此页面中有详细信息：
我建议看看关于这个主题的wwdc 2013演示文稿。
答案 4 :(得分：8)
我已经将CruiseControl与Xcode一起使用（类似于Pragmatic Automation建议的那样）并取得了合理的成功。我也非常熟悉CruiseControl，它的配置格式相对可怕。
我也使用了BuildBot效果很好，但发现它的优势并不能真正满足我的需求（分布式奴隶在多个不同系统中构建和报告）。配置buildbot设置本身就是一门艺术，虽然并不困难。它基本上都是用python编写脚本的。
自从Hudson上市以来，我建议将其作为运行持续集成的途径。它有一个基于Web的界面（CruiseControl在我的脑海中的主要缺陷），并且在它支持的各种系统中非常灵活。您可以非常轻松且非常明显地调用命令行驱动的构建。也就是说，我没有使用Hudson和Xcode建立一个实例，我在其他系统中也是这样，所以这是我的部分猜测。
答案 5 :(得分：4)
我认为你应该仍然可以使用Hudson。 Hudson非常灵活，您还可以使用shell脚本构建：Shell Scripts and Windows Batch Commands
只需输入xcodebuild即可。查看xcodebuild手册页以查看xcodebuild的选项。
答案 6 :(得分：4)
如果你不介意生活在最前沿，我刚刚为CruiseControl提交了xcode builder。
答案 7 :(得分：1)
詹金斯似乎对某些人有用。 （虽然我之前从未使用任何CI服务器。）
答案 8 :(得分：0)
詹金斯工作正常。 您可以通过编写自己的shell脚本来构建您的xcode项目，然后让Jenkins运行它，或者您也可以使用xcode插件。
但你必须意识到权威问题。通过Jenkins配置中的少量调整，您将能够在很短的时间内管理CI服务器。