iOS持续集成大比拼：Xcode Server、Jenkins、Travis和fastlane

版权声明

作者：The Code Bug

译者：大愚若智

原文： http://thebugcode.github.io/ios-continous-integration-choosing-a-build-server-and-tooling/

本文由作者授权翻译并发布，未经许可禁止转载。

正文：

我的团队去年曾两次历尽千辛万苦想要寻找一种能满足我们需求的持续集成（下文统一简称为CI）服务器。

考虑到之前CI方面的体验，以及我们的iOS开发者提出的各种需求，我们对这种服务器的要求是必须能够：

• 构建并发布不同版本的应用；

• 将我们的应用商店版本上传至iTunes Connect；

• 将IPA、dSYM，以及变更日志上传至HockeyApp；

• 针对发布和开发分支持续不断地运行单元测试和UI测试；

• 构建每次合并请求（MR）并汇报测试结果；

• 进行持续不断地构建和发布，以确保没有引入新的问题。

除了命令行工具，我们考虑过下面几个产品：

• xcodebuild - 由Apple开发，主要用于Xcode的构建和测试，有时可能难以想起，但可配置程度很高。

• fastlane - 实际上并不是一个工具，而是一组可用于构建、测试、上传至iTunes Connect、供应配置文件管理、屏幕截图创建、dsym上传/下载至主要崩溃报告平台的一系列工具。

• xctool和其他 - “其他”是指诸如nomad tools等工具，这些工具或者被弃用，或者逐渐缺少支持，或者即将被废弃。尽管Facebook在使用某种工具，但并不意味着这个工具依然可以得到妥善的维护。

后面的测试结果会告诉你最终被我们选中的冠军（继续读下去吧）。

与此同时，如果缺少持续不断运行所需的服务器，工具本身也毫无意义。有人推荐了几个CI服务器，具体如何选择，只要先决定打算将时间投入在哪里就行了。

服务器方面主要的选择包括：

• TravisCI/CircleCI - 托管式服务器，可免费用于开源项目，可随处访问，极为强大。相比Jenkins可配置的选项较少，仅支持与Github集成。用于私有代码库的价格高昂。

• Xcode Server - 能与Xcode高度集成，实际上也是唯一可用于Xcode的服务器，由Apple开发，最有可能只需要少量配置即可投入使用。

• Jenkins - CI服务器领域曾经的王者，有大量插件可用，可与各种其他产品集成，需要一定的配置和维护，但是非常强大。我们的考量：

一种围绕GitHub开发的，非常简单的CI服务器。重要：如果你想要使用它，但代码没有托管到GitHub，那么就很不幸了。由于价格原因，或出于安全的原因希望自行托管自己的代码，很多公司会使用GitHub的替代品，例如Bitbucket或Gitlab。但如果你的代码托管在Github，并且你愿意为Travis/Circle支付包月费用，可以在这里了解Travis支持的主流iOS库：AFNetworking：

https://travis-ci.org/AFNetworking/AFNetworking/branches

Travis的界面更为专注于构建的生成和Github Pull请求。该服务提供了拆箱即用的模拟器和Xcode镜像（你可以指定构建所要使用的Xcode版本）。Travis CI依然处于Beta测试阶段，可以周期性地运行作业，而Jenkins可是早在很久以前就提供这样的功能了。

优势：

• 拆箱即用，易于设置；

• 可配置，可根据需要维护Xcode和工具选项；

• 能与GitHub实现良好的集成；

• 提供了完善的文档，被开源社区广泛使用；

• 用户界面美观。

不足：

• 如果代码未托管在GitHub将无法使用；

• 付费计划价格高昂，构建能力有限；

• 相比Jenkins，配置选项和插件数量少很多。

结论：

最后，Travis以及CircleCI缺乏与Bitbucket和Gitlab的集成是我们无法接受的。我们的代码未托管到Github，就算托管了，我们需要持续不断运行构建和测试的需求也需要更多的构建时间（时间就是金钱，一点没错，CircleCI按照构建所进行的分钟数收费）。他们还缺乏完善的插件生态体系，这也让Jenkins显得更可人（我们能创建仪表板，或者在失败后重试构建3次，这些功能都是插件的功劳）。

由Apple开发，满足iOS（以及macOS？）开发者CI需求的CI服务器。Xcode Server（XCS）所谓的机器人（Bot），其实就是Jenkins的“作业”，两者是一回事，都是预先调度好的任务。Xcode Server在我们的项目导航界面显示的机器人是这样的：

用户可以决定是否让机器人运行单元测试或UI测试，可以分析甚至生成可供安装的IPA（归档操作）：

顺利执行了集成之后可以看到这样的概述信息，这可能是XCS最棒的功能了：

还有关于测试的概览。

关于如何与XCS配合使用，整个互联网上只有一篇粗略的指南，此文发布在Honza dworzky's：

https://honzadvorsky.com/articles/2015-08-04-xcs_tutorials_1_getting_started/

如果你想进一步了解如何配置XCS，建议阅读此文。这并非偶然，Honza现在已经加入Apple从事开发者工具相关的工作。

Xcode服务器也许更了解Xcode，但对持续集成知之甚少。该服务器可并行运行两个或更多作业（机器人），但无法接受Git子模块（Submodule）变更（可通过自定义脚本实现该功能）。如果你有需要持续运行，但与Xcode没太大关系的任务（例如每天下载localizable.strings的翻译），XCS必须首先构建或测试一些内容才能执行这些操作。如果XCS构建失败，Apple的“极简主义哲学”这时候就显露出来了，XCS只能显示一些简单并且含糊的错误信息（/usr/bin codesign failed）。