原文：3x3: iOS Build Speed and Stability
作者： Keqiu Hu 译者：杰微刊兼职翻译张万程
Voyager项目是为了开发LinkedIn新的旗舰级手机应用，去年年初，我们开始在项目中实践3x3哲学：
一天发布三次，从代码提交到用户可以使用，不超过三小时。
虽然我们不能每三个小时向App Store发布一次，但我们每天可以多次构建员工使用的企业产品。“3x3”听起来很快很容易，但说起来容易做起来难。三小时一发布的节奏，让我们没有时间做手工测试，所我们需要一个通道：
1.从代码提交到产品发布，每个环节都完全自动化
2.可靠性要好，甚至要高于手工测试
3.速度足够快，能够适应我们三个小时的窗口期
4.稳定性，确保每个合法提交都会被发布
今年年初的时候，Drew Hannay在他的博客，3x3：加速手机应用的发布中简要介绍了手机应用3x3哲学。围绕快速和稳定构造，我们将深入探索3x3在iOS应用开发中的应用。
第一部分：速度
为了获得一个从代码提交到发布小于三小时的通道，我们通过重构Swift代码，加速编译速度，加速我们的UI测试框架，构造和测试并行等手段，以优化我们的构造通道。
加速代码编译
我们选择Swift做为新的旗舰级应用Voyager的主力开发语言，从最早的1.0到2.0随着Swift的不断升级，我们的项目也在不断演变。
在Voyager项目早期，我们非常享受Swift的易用和先进的功能，但漫长的编译时间长长令我们沮丧。随着起来越多的代码提交到我们的iOS代码库（每天大约60次提交）， 我们发现即便只有少数文件发生变更，编译时间也呈指数增长，从数秒到30分钟左右。更糟糕的是发布构建时间比调试构建时间更长，通常需要2个小时。秉承“测试要与开发同步”的原则，我们要另外再花两个半小时来写150个KIF测试。结果，我们需要花四个半小时完成从提交到发布的过程！
为了缓解开发者的挫败感，我们通过Apple开发者社区，Apple开发者论坛和公司合作伙伴关系努力与Apple工程师沟通。并就如何缩短我们的构建时间，获得了很多宝贵的反馈意见。 Jacek Suliga负责一个主要代码库的重构，将我们的工程分成不同的子项目和模块，用显式引用取代隐式引用。这使得调试构建时间几乎缩短了一半，发布构建时间从原来的2小时缩短到35分钟，从提交到发布时间缩短到3个小时。对于本地开发，我们为每个iOS开发人员购置了一台Mac Pro，以减少调试构建时间。
UI测试框架优化
构建时间优化之后，UI测试时间成为瓶颈。Jacek在 UI自动化：保持实用和稳定一文中介绍了我们如何优化开源项目KIF，让它可以5到10倍地提速。这大大缩短了测试时间，测试运行时间缩短了80%，只需要大概20分钟时间。然而，测试越来越多，一个月内增长了四倍，测试时间增长到80分钟，总时间增长到2个小时。
在对编译和UI测试框架做了优化之后，我们认为只有技术创新才能显著解决从提交到发布的时间问题，我们将重点放到了：分布式构建和测试。
分布式构建和测试
我们与基础设施团队密切合作，为iOS和Android提供分布式编译和测试支持。当我们将所有构建和测试任务分发到10台机器上，唯一的瓶颈就变成了发布构建时间，加上一些工具开销，需要35分钟完成。提交到发布的总时间下降到45分钟。使用更多的机器可以进一步提高构建时间，但是也会引入一些可靠性问题，我会在稳定性部分阐述
第二部分：稳定性
在我们的构建通道中，从提交到发布，有两个关键组件会影响整体稳定性：测试系统的稳定性和构建工具的稳定性。
1. 测试系统稳定性
在我以前的博客：测试稳定性 - 我们如何让UI测试变得稳定，我讨论了我们如何构建稳定的测试环境。主是是稳定的测试环境，从测试框架中移除不可预测的因素，净化我们的测试组件。请重温一下那篇博客，关于我们如何让我们的测试基础设施变得稳定的细节。
2. 工具稳定性
2.1 硬件稳定性
我们通过cfengine集中管理我们的机器池，现在我们有两类Apple硬件：
Mac Mini (2012年版)
①处理器 2.6GHz Quad-Core Intel Core i7
②内存 16GB 1600 MHz DDR3
③存储 1TB HDD
④Intel HD 显卡
Mac Mini (2014年版)
①处理器 3.0GHz Dual-Core Intel Core i7
②内存 16GB 1600MHz LPDDR3 SDRAM
③存储 512GB PCIe-based Flash Storage
④Intel Iris 显卡
有一次，我们看到建构池中出现内存问题，有10%的机器活动内存小于100MB，大量使用交换分区。当检查这些内存不够用的机器时，我们发现在后台有20多个长期运行的xcodebuild进程。我们意识到这是此前挂起的xcodebuild进程所致。
为了解决这个问题，我们采取了以下行动：
1. 添加重试逻辑，在运行新的任务前，清除所有挂起的xcodebuild进程。
2. 对有可能导致内存溢出的服务每天定期重启。
3. 对交换分区使用较多的机器设置自动报警。
2.2 Mac 系统构建环境稳定性
除了内存问题，我们偶尔也会发现机器上有运行iOS模拟器问题，这些问题影响了整体稳定性。一旦机器上出现模拟器问题，如果不正确处理，它会影响这台机器接下来的所有构建任务。我们曾经付出巨大的努力来解决模拟器问题（参见：企业级iOS持续集成管理），但当我们尝试解决这个问题时，发现还不如先前的效果，因为模拟器工具并不在我们的控制之中。
幸运的是，我们发现重启可以解决绝大部分模拟器问题。我们启动了一个叫PoolGuardian的项目，用来监控所有构建机器，并且定期检查是否有机器出现模拟器问题，如果发现有问题，它会重启这台机器，并且在重新使用这台机器前会做健康检查。
2.3 并行测试稳定性
分布式测试看起来很有前景，因为它确实解决了我们的速度难题，但是当我们遇到一些可靠性问题时，我们意识到它是一把双刃剑。
在我们的Mac系统工具链环境中，我们遇到一些Apple开发者工具链问题，包括间歇性编译崩溃，模拟器崩溃，模拟器重复性错误，和环境错误问题。总之，每天机器的稳定性大概在95%左右。看起来好像还不错，但是在分布式测试中，只有所有子任务全部通过，一个构建才能完成，确切一点说，10个子任务要全部通过。所以每加一个节点，总体可靠性下降到原来的95%，随着结点数的增加，整体可靠性呈指数下降。如果使用10个结点，工具链的可靠性下降到95%10 ≈ 60%。
为了改善上面提到的工具链可靠性问题，我们优化了我们的构建池，使用种种手段让我们的 Max OS X更加可靠。通过这些努力，工具链的稳定性从95%提高到略高于98%。加上其他结点，稳定性仍然有98%10 = 82%。这远远没有达到我们的预期—99%的可靠性。但是解决x10 = 99%需要 x = 99.9%，这就需要99.9%的机器可靠性，这需要更多的资源和精力。
同时，我们试图跳出这个怪圈，我们希望在高可靠性的同时，我们的构建通道可以快速完成提交到发布过程。然后我们有了一个突破：如果我们把所有任务都放到一个测试结点，同时使用多个模拟器跑测试会怎么样？基于这个想法产生了Hydra项目，Hydra的总体目标是：
1. 在一台服务器上使用多个模拟器并行跑测试，让构建时间提高5到10倍。
2. 启用不同模拟器之间的交互测试（iOS与iOS, Android与Android ，iOS与Android）
在这篇博客中，我只涉及第一个目标。下图是多模拟器测试架构。
当一个提交发生后，测试运行器会构建应用并启动5个模拟器用来组成一个模拟器设备池。构建完成后，测试运行器将查询测试集群，获取一个测试类列表。根据测试用例的数目，测试类会动态分配到20个单元中，并形成一个测试队列。一旦初始化阶段完成，设备池会不断地获取测试任务并运行。同时设备池有一个健康监测进程保证设备池的健康运行。一个测试任务结束后，测试成果和测试报告会被收集并上传到持续集成工具，等待下一个发布周期。
你可能会问，为什么我们选择运行5个模拟器，这是因为OS对每个shell会话的进程有个默认限制，在Mac Mini上是709。每个模拟器会产生大约70个进程。当我们添加300个MacOS系统进程，我们同时只需启动5到6个模拟器。我们曾经试图取消shell进程限制数，但是当超过700个进程时，OS环境会变得很脆弱。所以，权衡扩展性和可靠性，我们选择5个模拟器。
有了Hydra的帮助，我们的构建稳定性从最初的0提高到今天的90%，而且我们还在不断的优化它。下图是一个示例，我们会以我们的方式开源这个项目，敬请关注！
致谢
如果没有包括工具，测试，移动基础设施和其他LinkedIn团队的专业协作，我们不可能完成这些，谢谢大家。
网友评论