欢迎再次来到我们的虚拟炉边,Wayfair工程爱好者。让自己舒服一点,开始我们关于持续集成的炉边故事系列的第二部分。如果你不喜欢,请读一读第一部分,Wayfair的GitLab CI历史。本期文章将介绍GitLab CI的继任者Buildkite。

你不能离开中心

作为对上一篇文章的复习,我们建立了GitLab CI,目的是使构建系统更易于维护和稳定。我们所做的实现选择没有达到我们的预期,我们需要彻底改革我们的系统如何站起来解决问题。

当前的构建系统将重点放在为普通的Wayfairian用户检入代码的能力上。这是一个常见的事件,大约在Cyber5 2018年,我们会看到GitLab完全崩溃小时一次,一周好几天。这在很大程度上是由于我们的CI系统及其难以置信的负载阻碍了GitLab跟上开发人员生成平均流量的能力。

GitLab本身就是一个极好的设备。然而,多年的务实选择和技术债务留给我们的是一个维护不善的例子;还有许多糟糕的做法和开发人员的不信任。如果我们能够进行切换,我们希望看到GitHub比我们目前使用GitLab所经历的时间更长。这将有助于我们赢得信任,减少团队的辛苦。

这极大地简化了我们与现有系统之间的技术障碍(即,代码库中不经常发生的产品中断事件无法访问)。我将简化这个故事,指出与我们最终如何使用GitHub和Buildkite相关的重要变化:我们需要大修,或者重新开始。在本例中,在两个版本控制系统之间,我们从GitHub重新开始。

有什么不对的地方可以减轻大脑疼痛呢?

此时,所有php、js、windows、python和一些java应用程序都依赖于GitLab CI基础设施。我们将Jenkins和Octopus用于各种管道中的其他阶段,但是GitLab CI已经巩固了自己,成为我们如何部署和验证代码的关键部分。我们没有按照几年来所达到的规模构建基础设施,也没有随着不断增长的组织的开发人员需求的变化而维护基础设施。我们的系统也不是以可重复的方式创建的(参见:基础设施不是代码)。在用户体验领域,我们遇到了大量的问题,应用程序团队不断更改共享管道。当我们考虑这些问题时,我们发现了这家澳大利亚公司,建筑风筝.

Buildkite提供了将其SaaS用于构建基础设施前端的能力,这缓解了我们在基础设施降低了检查构建和验证代码能力方面遇到的任何问题。Buildkite也提供了一些独特的测试空间,动态管线. 为了戏剧性地过于简单化,动态管道允许我们对需要在管道中执行的内容进行动态决策。因此,我们在一个.yml文件中没有成百上千行(是的,实际上)来创建生产-构建管道。当我们知道需要自动化时,我们可以通过编程方式发送构建、测试和/或部署自动化的某些步骤。

我们还发现特别令人兴奋的是:Buildkite有一个开源代理(以前是GitRunner的代理),我们用它来接受Wayfair开发人员的工作。我们可以根据需要对我们的产品进行调整和错误修复支持的用例,使Wayfair更具吸引力开放源代码存在. 除了对代理本身的修改之外,我们还能够为Buildkite插件做出贡献:可以为Wayfair特定案例创建可重用的功能,并反馈给GitHub上更广泛的社区。我们也有能力钩子,我们可以嵌入代理中的小脚本,大大简化了我们为保持基础结构稳定、可重复和可靠而实施的过程。

最引人注目的是,正如我们在GitLab中学到的,我们需要开发团队的支持运营团队为我们的管道实现并维护稳定的基础设施。我们有专门的资源(像我自己!)调查并声称拥有从GitLab CI到Buildkite我们可以改进的东西。我们开始着手使用infra,为我们如何与开发人员团队合作提供基础。

完善和定义标题和副业管道指南和限制

正如我们在上面和上一篇文章中提到的,GitLab CI代理并不总是以可复制的方式组合在一起。我们没有一个地方来查找所有依赖项和代理的预期用法。为了改变Buildkite的这种情况,我们收集了尽可能多的关于GitLab CI基础设施的知识。我们的基本知识是,我们肯定需要我们自己和基础设施团队之间的协调,比如网络和安全。我们想确保我们对这个问题有足够的了解,这样我们就不会再重复这个问题,继续新的基础设施需求的循环。我们确定了我们期望达到的几个参数:

  • 我们需要几个队列来避免“把所有的东西都放在每个代理上”
    • 菲律宾比索
    • Javascript语言
    • Windows(点网)
    • 默认值(管道上载步骤没有依赖项)
    • 我们还无法预测的工作流的“实验”队列(docker成为了我们用于实验的名称+技术,它现在是最大的队列!)
  • 我们需要一种方法来存储不是GCP或S3的工件
    • 你们中的一些人可能知道,现在我们确实依赖GCP来存储工件。当时,我们没有对Buildkite工件使用GCP,这与安全问题有关,这些问题已经得到解决。
  • 我们需要Windows代理

这不是我们详尽的清单,但这些是最有趣的出发点。我们构建了开放源代码,发布了标准,并与各个团队合作,以确保所有monorepo都具有特定于管道的所有权。设置寻呼机、随叫随到、获得基础设施权限以推188金博宝备用动我们自己的发展、编写WOC运行手册,以及在整个组织内进行协作;我们实现了Buildkite基础设施的第一个版本,可以从GitLab接管。

在这个时候,GitLab至少花了半个小时来运行所有的测试以进入集成器。大多数情况下,这是一个多小时,你将不得不运行他们多次。更糟糕的是,当它到达积分器时,它们必须再次运行。我们决定需要一个更好的系统,PHP平台整合了一种使用动态管道来运行动态测试套件的方法。这是一种很奇特的方式,我们将它们分成10个序列,因此每个套件需要3-5分钟,而不是每次连续运行所有35000个测试。

我们还注意到,许多单元测试都涉及到外部服务,这使得结果变得不可预测。这不是单元测试的目的,所以我们对单元测试进行了一次大规模审计和跳过。我们跳过了大约20%的测试,然后把其余的放进一个不能接触到外界的容器中,以确保问题不会再次出现。我们期望有显著的改进,但这实际上消除了我们期望从单元测试中得到的典型片状。任何期望达到的测试都会持续失败,并且无法进入主分支!

有了可靠的基础设施和轮流维护,所有这些都变得更加可能。随着我们作为一个组织和CI战略的不断发展,我们不断完善Buildkite的需求以及我们需要做什么来确保我们为组织服务。

展望未来

作为Buildkite的建设者之一,看到平台已经走了多远真是太棒了。我们继续改进webstack的开发过程,使开发人员更加容易。Wayfair的许多工程师都依赖Buildkite,我们希望有一天能让它变得如此流畅,让新的工程师把它当作一个细节。我们永远不会完全完成,但看到应用程序开发过程中如此痛苦的部分从去年的这个时候开始得到改善,感觉很好。

我很高兴您抽出时间来阅读这段历史,并感谢有机会分享Wayfair旅程中的这一章。如有任何问题或更正,请联系我gwhite@wayfair.com-我们很高兴收到你的来信。