Coinbase的持续集成：我们如何优化CircleCI以提高速度并将构建时间缩短75％

调整持续集成服务器是一项有趣的挑战 - 基础架构工程师需要在系统上平衡构建速度，成本和队列时间，许多开发人员都没有大规模管理的丰富经验。如果做得对，结果可能是贵公司的一大利益，正如我们最近为改进CI设置所做的那样。

Coinbase的持续集成

随着Coinbase的发展，让我们的开发人员对我们的内部工具感到满意是我们的首要任务。对于Coinbase的大部分历史，我们使用了CircleCI服务器 ，这是一个高性能且低维护的工具。然而，随着公司和我们的代码库的增长，对CI服务器的需求也在增加。在此处描述的优化之前，运行Coinbase.com的单轨应用程序的构建的长度显着增加（之前平均构建时间翻倍或三倍），并且开发人员通常抱怨冗长或非完成构建。

我们的CI构建不再满足我们的期望，并且考虑到之前的问题，我们决定开展一项活动，以使我们的设置恢复正常。

值得分享的是，Coinbase专门使用CircleCI的内部服务器版本而不是他们的云产品 - 出于安全原因，托管我们自己的基础架构对我们很重要，这些概念特别适用于自我管理的CI群集。

四个金色信号

我们发现优化任何CI系统的第一个关键是可观察性，因为如果没有办法衡量调整和变化的影响，就不可能真正知道你是否真的做了改进。在我们的例子中，服务器托管的CircleCI使用nomad集群进行构建，并且当时没有提供任何监视集群或其中节点的方法。我们必须构建自己的系统，我们决定使用四个黄金信号的框架，即延迟，流量，错误和饱和度 。

潜伏

延迟是服务请求所花费的总时间。在CI系统中，这可以被认为是构建从开始到结束所花费的总时间。在每个存储库甚至每个构建基础上更好地测量延迟，因为基于项目，构建长度可能会有很大差异。

为了衡量这一点，我们构建了一个小型应用程序，定期查询CircleCI的API以获取构建长度，然后将该信息传递给Datadog ，以便我们构建平均构建时间的图形和可视化。这使我们能够根据经验和自动情况绘制改进实验的结果，而不是像我们之前所做的那样依赖轶事或手动策划的结果。

交通

流量是指任何时候对您的系统的需求量。在CI系统中，这可以由并发运行的构建的总数来表示。

我们能够通过使用我们构建的用于测量延迟指标的相同系统来衡量这一点。这在确定使用我们的构建资源的上限和下限时派上用场，因为它允许我们确切地查看在任何时间运行的作业数量。

错误

错误是失败的请求或调用的总量。在CI系统中，这可以由因基础结构原因而失败的构建总数来表示。这里重要的是要区分由于测试，linting，代码错误等而导致正确失败的构建，而不是由于平台问题而导致构建失败的构建。

我们遇到的一个问题是，在启动运行速度比普通“好”实例慢得多的新构建器时，AWS偶尔会给我们“坏”实例。在我们的构建器启动脚本中添加错误检测允许我们终止这些并启动新节点，然后才能减慢我们正在运行的构建。

饱和

饱和度是指您的服务“完整”，或者您使用了多少系统资源。在CI系统中，这非常简单 - 负载使用的构建器有多少I / O，CPU和内存。

为了测量我们设置的饱和度，我们可以通过在每个构建器上安装Datadog Agent来获取群集指标，这样我们就可以查看整个群集中的系统统计信息。

确定根本原因

一旦您的监控设置到位，就可以更轻松地深入了解构建速度下降的根本原因。在没有群集范围监视的情况下诊断CI问题的困难之一是，很难确定哪个构建器在任何时候都遇到负载或者该负载如何影响您的构建。延迟监控可以让您确定哪些构建时间最长，饱和度监控可以让您识别运行这些构建的节点，以便进行更深入的调查。

对我们来说，我们添加的新延迟测量使我们能够快速确认我们之前猜测的内容：并非每个版本都相同。有些构建版本以我们之前遇到的快速速度运行，但其他版本的版本会比我们预期的要长得多。

在我们的案例中，这一发现是一个重大突破 - 一旦我们能够快速识别具有延迟增加的构建并找到饱和节点，问题就会迅速显现出来： 开始构建之间的资源争用！由于我们大型构建的大量测试，我们使用CircleCI的并行化功能来拆分我们的测试，并在单独的docker容器中跨越机群运行它们。每个测试容器还需要另一组支持容器（Redis，MongoDB等）以复制生产环境。为每个构建启动所有必需的容器是一项资源密集型操作，需要大量的I / O和CPU。由于Nomad使用bin-packing进行作业分配，我们的构建者有时会同时启动多达5组不同的容器，在测试开始运行之前会造成大量的减速。

构建实验

设置开发环境是调试CI问题的关键，因为它可以让您将系统推向极限，同时确保您的测试不会影响生产中的生产力。 Coinbase为CircleCI维护了一个开发集群，我们用它来测试新版本，然后再将它们推向生产，但为了调查我们的选项，我们将集群转换为生产实例的较小副本，使我们能够有效地加载测试CircleCI构建器。保持您的开发集群尽可能接近生产可以帮助确保您找到的任何解决方案都反映出在真实环境中实际可以提供哪些帮助。

一旦我们确定了为什么我们的构建遇到问题，并且我们建立了一个运行实验的环境，我们就可以开始开发解决方案。我们反复运行相同的大型构建，这些大型构建在我们的生产集群上导致不同大小和类型的EC2实例出现问题，以便找出哪个是最具时间性和成本效益的选项。

虽然我们以前使用较少数量的大型实例来运行我们的构建，但事实证明我们的集群的最佳设置实际上是非常大量的小实例 （在我们的例子中是m5.larges） - 小到足以使CircleCI只运送一个并行化构建容器到每个实例，防止构建践踏问题，这是导致减速的原因。识别正确实例类型的一个很好的副作用是它实际上允许我们显着降低服务器成本占用空间，因为我们能够更紧密地调整集群的使用量。

问题？解决了！

将更改应用于生产环境是最后一步。确定调谐效果是否有效可以通过四个黄金信号确定问题。

在我们确定了在我们的开发群集中最有效的方法之后，我们很快就在生产中实施了新的构建器大小。结果？ 我们最大的构建的构建时间减少了75％，由于我们的集群规模正确，显着节省了成本，最重要的是：开发人员满意！

Coinbase的持续集成：我们如何优化CircleCI以提高速度并缩短我们的构建时间......最初发布于The Coinbase Blog on Medium，人们通过突出显示和回应这个故事来继续对话。