我的团队去年曾两次历尽千辛万苦想要寻找一种能满足我们需求的持续集成（下文统一简称为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服务器领域曾经的王者，有大量插件可用，可与各种其他产品集成，需要一定的配置和维护，但是非常强大。
我们的考量：
1.TravisCI
一种围绕GitHub开发的，非常简单的CI服务器。重要：如果你的代码没有托管到GitHub，那么就很不幸了。由于价格原因，或出于安全的原因希望自行托管自己的代码，很多公司会使用GitHub的替代品，例如Bitbucket或Gitlab。但如果你的代码托管在Github，并且你愿意为Travis/Circle支付包月费用，可以在这里了解Travis这一流行的iOS库：AFNetworking。
Travis的界面更为专注于构建的生成和Github Pull请求。该服务提供了拆箱即用的模拟器和Xcode镜像（你可以指定构建所要使用的Xcode版本）。Travis
CI依然处于Beta测试阶段，可以周期性地运行作业，而Jenkins可是早在很久以前就提供这样的功能了。
优势：
拆箱即用，易于设置；
可配置，可根据需要维护Xcode和工具选项；
能与GitHub实现良好的集成；
提供了完善的文档，被开源社区广泛使用；
用户界面美观。
不足：
如果代码未托管在GitHub将无法使用；
付费计划价格高昂，构建能力有限；
相比Jenkins，配置选项和插件数量少很多。
结论：最后，Travis以及CircleCI缺乏与Bitbucket和Gitlab的集成是我们无法接受的。我们的代码未托管到Github，就算托管了，我们需要持续不断运行构建和测试的需求也需要更多的构建时间（时间就是金钱，一点没错，CircleCI按照构建所进行的分钟数收费）。他们还缺乏完善的插件生态体系，这也让Jenkins显得更可人（我们能创建仪表板，或者在失败后重试构建3次，这些功能都是插件的功劳）。
2. Xcode Server
由Apple开发，满足iOS（以及macOS？）开发者CI需求的CI服务器。Xcode
Server（XCS）所谓的机器人（Bot），其实就是Jenkins的“作业”，两者是一回事，都是预先调度好的任务。Xcode
Server在我们的项目导航界面显示的机器人是这样的：
用户可以决定是否让机器人运行单元测试或UI测试，可以分析甚至生成可供安装的IPA（归档操作）：
顺利执行了集成之后可以看到这样的概述信息，这可能是XCS最棒的功能了：
还有关于测试的概览。
关于如何与XCS配合使用，整个互联网上只有一篇粗略的指南，此文发布在Honza dworzky's。如果你想进一步了解如何配置XCS，建议阅读此文。当然也并非偶然，Honza现在已经加入Apple从事开发者工具相关的工作。
Xcode服务器也许更了解Xcode，但对持续集成知之甚少。该服务器可并行运行两个或更多作业（机器人），但无法接受Git子模块（Submodule）变更（可通过自定义脚本实现该功能）。如果你有需要持续运行，但与Xcode没太大关系的任务（例如每天下载localizable.strings的翻译），XCS必须首先构建或测试一些内容才能执行这些操作。如果XCS构建失败，Apple的“极简主义哲学”这时候就显露出来了，XCS只能显示一些简单并且含糊的错误信息（/usr/bin
codesign failed）。
最糟糕的地方在于，XCS构建和测试之外的一切，必须使用XCS提供的极为有限的API自行创建。无法与Gitlab/Bitbucket/Github集成，没有可用于与无作业流程的API进行通信的插件。实际上，XCS**唯一**能做的就是在设备上运行单元测试和UI测试。尽管如此，如果测试失败，它也不会告诉你原因，你只能自己揣摩了。
优势：
能与Xcode实现良好的集成；
一切均拆箱可用；
提供了用于监视机器人的Web仪表板；
能创建可安装的IPA，并能通过Web仪表板安装。
不足：
在一些基本任务方面有所问题，例如有子模块，需要将源代码签出时；
无法添加多个构建器节点，机器人运行速度缓慢，无法纵向扩展；
过于专注于与XCode本身有关的任务，无法运行其他类型的作业；
几乎无法实现与第三方的集成；
无法对构建问题进行调试；
只适合单元测试和UI测试。
结论：
Apple很明显并不打算开发一种完备的CI服务器。也许该产品主要是以小型团队和独立开发者为目标。在针对XCS进行过大量试验后，我们觉得就算小型团队，也很难在合理时间里通过XCS进行维护、保活、调试和反馈等任务。
就算你不会遇到这类问题，XCS也无法提供构建和测试之外的其他任何功能。上传至iTC、供应配置文件下载和安装、上传至Hockey
app（或Fabric）、将测试结果汇报给Git代码库管理者，其他各类CI任务都不被XCS支持，因此相比我们最终选择的产品，XCS的实用性大打折扣。
3. Jenkins + fastlane
这个组合略有不同，因为需要针对fastlane的概念和用途进行一个简单的介绍。
Fastlane是一组命令行工具，可供开发者构建自己的应用：
fastlane gym --scheme YourSchemeName |
或运行单元测试：
fastlane scan --scheme YourSchemeName |
或针对特定设备运行UI测试：
fastlane scan --scheme UITestsScheme --devices 'iPhone 5s' |
甚至可以上传应用进行试运行：
fastlane pilot upload --ipa PathToIpa |
这四个简单的操作完全满足了本文开头列出的需求。Fastlane还有更多其他功能（例如供应配置文件下载和安装），但上面这几个命令对我们来说已经够用了。
由于fastlane命令非常简单并且可移植，并能通过Fastfile将其放入源代码控制系统，因此只需很少的工作，甚至无须任何准备，即可迁移至任何CI服务器，因为Fastfile实际上是一种应用构建、测试、分发过程中使用的“菜谱”，而服务器只不过是执行这些工作的场所。
继续说Jenkins。Jenkins是一种Web服务器，可在任何计算机（包括撰写本文所用的MacBook）上运行。安装好后看起来是这样的：
通过使用上文介绍的fastlane命令，开发者可以轻松创建各种作业，例如调用相应的fastlane scan命令执行单元测试和UI测试。若要创建构建并上传作业，调用fastlane
gym和fastlane pilot即可。通过使用GIT parameter（一种Git参数插件）将作业参数化，即可从任何分支触发构建：
合并请求构建器是个很有趣的用例。它可以被每个合并请求触发，执行单元测试（fastlane scan）并将结果汇报给Gitlab。通过使用Gitlab插件（上文介绍的服务器均不具备），在变更推出后只需点几下按钮即可进行构建：
同时会在Gitlab、Bitbucket的提交旁边通过绿色对勾（或红叉）汇报结果。
借助强大的Build Monitor View插件，开发者可以通过下面这样美观的视图添加运行单元测试和UI测试的作业：
如果需要更细化的粒度，可以通过fastlane轻松地指定UI测试要使用的仿真器（fastlane scan
--scheme UITestsSchema --devices 'iPhone 4S'），此外还可创建更细化的UI测试仪表板，将通过fastlane
scan调用不同仿真器的最多六个作业汇总在一起：
其他作业可以每天使用fastlane sigh更新并下载之前供应的配置文件。处理完每个合并请求后，其他作业可以为测试者创建构建并将其上传至hockeyApp。当新构建可用时发送包含变更日志和下载链接的可宽延通知信息？一切皆可能。
Jenkins可通过增加构建器节点的方式进行纵向扩展，这个功能竟然是免费的，因此也值得一提。Jenkins唯一的不足在于由于是免费的，用户需要自行托管并维护。该产品的界面一直不怎么美观。除此之外，该产品的插件、稳定性、可靠性，以及与各类第三方服务的集成能力都是顶尖的。
结论
就算小团队也可以使用fastlane让iOS应用的开发过程（构建、上传、测试）实现自动化。配置可运行这些fastlane命令的Jenkins服务器，操作过程并不难，随后再也不需要专门指定一个团队成员盯着终端长达数小时时间关注这些命令的运行。良好且透明的错误处理机制是fastlane的主要目标之一，通过与Jenkins服务器配合使用，将能为团队提供一个强大的解决方案。Fastlane完善的文档和已获证实的稳定性，以及大量的插件，使得Jenkins可以帮你将更多不同流程实现自动化。所有工作一键点击即可完成。Xcode
Server的差距太大，其他CI服务器功能没这么强大（仅支持Github），因此Jenkins顺利成为我们首选的CI服务器。
附注：我依然在试图让Xcode Server成为我们CI环境的一份子，我打算通过它在物理设备上运行UI测试。XCS是否能胜任至少这一个任务，或者彻底被我们卸载，结果还有待观察。
|
