为什么 Slow builds 是发布人员永远的噩梦

发布经理身处于不断加快发布效率的竞争环境中，已经是个长久的问题。然而在敏捷和持续集成/持续交付的开发方法影响下，这个问题越来越明显。Facebook、Amazon、Netflix、Google 等科技巨头正以飞速的节奏进行每天数千次的更新发布。特别是亚马逊，以每 11.6 秒就有新的产品部署而在业内出名。

发布经理正面临更短的发布周期，比以往任何时候都频繁，同时还要按时交付高质量的发布成果。在这样的压力环境下，创造出一套能够支持不断开发、测试、发布和拥有部署能力的基础结构是非常重要的。为了达到这一目的，发布经理应该熟练掌握使用这样定义明确的基础结构。同时它需要制定适当的工具和流程，来确保按时完成工作的同时保证产品的质量。

在这个基础设施难题中，如何有效缩减编译时间就是一个不容忽视的重要议题。

对于发布经理来说，编译的快慢是一个棘手的问题。为啥呢？显然是编译耗时长，另外还有些其他原因导致发布经理会如此惧怕慢速编译：

01 影响编译的因素

在现实工作中，编译经常失败，大概频率是多久一次？不同组织发表的数据都不同，但是根据 eBay 高级 DevOps 架构师 Eitan Schichmanter 预估：“15%-30% 的编译会因为各种原因在发布分支上失败”。

那么是谁担负起了责任，来找出编译失败的原因并且修复它呢？

发布经理就像是开发团队的幼儿园教师一样，和开发团队就像是玩捉迷藏。假设现在有一个 commits 了20次的编译。为了找到导致编译失败的原因，需要进行 20 次修改。这样做非常浪费时间，更不用说其他更难处理的情况。

过慢的编译和这样的情况之间有什么联系呢？假设编译速度很慢，那么你就不能执行你很想应用的 build-pre-commit 技术，这也意味着在运行编译之前你堆积了很多次 commits.反之，如果你的编译速度很快，那你可以执行 build-pre-commit 命令，并且任何时候都可以准确知道是哪里有问题。实际上，你甚至不需要知道问题所在，自动化将向影响编译的开发人员发出相应警告，这样你就可以专注于优化 DevOps 流程。关于 build-per-commit 的另一件事是，根据定义，它将通过封闭签入来确保清晰的编译，这就引出了我们的下一个观点。

02 不完美的编译

人们喜欢清晰的编译，拥有一套清晰完整的编译流程意味着你可以随时使用它。这对于时间紧迫或者身处于最后发布截止日期的压力下的团队来说非常重要。想象一下以下场景(如果你已经遇见过了这样的情况，那就不需要想象了)：

开发人员小李修复了一个 Bug，该 Bug 支持与重要客户共享，但是由于开发人员小王破坏了主分支，所以在 Bug 修复之前无法与客户共享，这时没有一个完整的编译可以发布。而且，由于编译失败，产品质量测试(QA)不能开始测试新版本，所以整个进度都被拖延。

然而，因为拥有 (build-per-commit)，你可以随时有清晰的编译，需要使用时随时可以发布。

03 发布经理容易在质量问题上妥协

现实中并不存在十全十美的情况，更何况追求完美非常耗时。在一天快要结束时，大多数人都会认为“够好了”就可以了。在软件开发业务中，运行更少的测试和代码分析过程意味在质量问题上妥协，因为运行测试和代码分析使构建过程更长。过慢的编译过程会导致团队对自动化测试套件的依赖减少，编写测试越来越少，降低运行测试的频率，并缩小执行测试的范围。简化代码分析过程意味着你的代码不会因为质量问题(比如复杂性、依赖性、代码度量等)而被标记。

这个问题在《2019 持续加快联合编译指南》2019 Guide to faster Continuous Integration builds 中得到进一步程度的讨论。判断底线是：想满足于“够好了”，还是更坏的情况，冒着产品变糟的风险？

04 编译慢会阻碍未来发展

你是否考虑过未来编译能力是什么样子的? 如果没有，现在就应该开始考虑了。让我们假设正常情况下，你的代码会变得更强大。除此以外，你还需要添加额外的开放源码或第三方库，并扩展您的测试范围。但是，如果已经受够了缓慢的编译带来的折磨，那么自然而然会想要避免做任何增加编译时间的事情。你会发现自己拒绝使用能提升产品质量的工具和流程，因为他们会增加你的编译时间。这种会引起恶性循环的做法，最终会导致你落后于他人。

05 高峰时期编译效率低，无疑是灾难

即使你不会因为过慢的编译速度而烦恼，也无法保证在新版本发布前的任何高峰时期或者需要处理快速修复时没有类似情况。

以游戏产业为例，从我们的经验来看，当假期来临的时候，太慢的编译速度无法承受高峰的压力，而发布经理们就将留下一个所谓的灾难性场面: 无法如期发布。

那么问题来了，该如何提升编译速度呢？

令人惊讶的是，缩短编译时间并没有你想象中的那么难。

当然，有一些技术可以减少你的编译时间，比如《编译加速完全指南》The complete guide to speeding up your builds，这些技术需要投入很多精力(例如使用 PCH)，减少依赖性等等。

还有一种方法可以显著缩短编译时间(胜过上文提到的那些技术)，而无需更改你的代码或购买额外的硬件，它与实现分布式计算机解决方案(A distributed computing solution) 有关。

分布式计算机解决方案是在本地网络中的多台计算机上同时运行所有耗时的软件开发进程，比如编译。这种并行性允许将每台计算机转换为多核虚拟 HPC 机器，并且使用用户已经拥有的其他计算机的 CPU 功率。简单地说，通过利用内网中其他计算机的 CPU，你可以更快地进行编译和完成其他耗时的任务。

Walking the walk

在已经有自动驾驶汽车和可以打印披萨的 3D 打印机时代，仍然有很多发布经理在和缓慢的编译速度斗争。当涉及到快速发行与 CI 周期时，大家只是习惯性抱怨一下，但并不能付诸行动。这其实并不困难， 发布经理所需要做的就是意识到过慢的编译速度是一个应该被避免的基础潜在危害，同时尝试去提升编译速度。

点击了解 Incredibuild 加速 CI 构建编译的解决方案，并获取试用 License！