我们是如何改善部署GitHub的方式的

在过去的一年里,GitHub中为开发GitHub.com应用程序做出贡献的主要人员数量翻了一番。从表面上看,这似乎是一件好事,但同时为核心软件做出贡献的人员数量增长了2倍,这暴露出在工具使用上的一些问题。一年前为我们所用的工具不再发挥相同的功能,尽管GitHub本身是推动GitHub变革的绝佳工具,但部署工具和协调并没有取得同样的成功,其中的例子就是我们的部署。

GitHub.com主要使用分支部署模型通过chatops进行部署(在合并到主分支之前先部署分支)。这意味着开发人员可以将做出的更改添加到队列,检查队列的状态以及组织要部署和合并的拉取请求组。所有这一切都在名为#dotcom-ops房间中Slack里的Chatops来实现。尽管这是一个非常简单的系统,但由于需要在一个聊天室中同时管理许多人的队列、部署和许多其他任务,因此在监视部署时会引起一些混乱。曾经作为关键信息系统核心部分的这个渠道突然被允许推送的大量信息所淹没。

这只是分布在数百条消息中的大约十二个步骤中的一步,很难跟踪和验证部署状态。

建造

在今年夏季开始,我们开始着手彻底改变我们更改GitHub.com监控部署的方式。考虑到这个问题-即通过chatops进行多步骤、信息密集的部署过程-我们提出了一些主要目标:

简化开发人员的部署

我们之前系统遇到的主要问题之一是,在Slack通道内通过大量不同的消息跟踪了部署,这使得将组成单个部署的消息拼凑起来非常困难。有时,来自部署系统的后续消息之间可能有多达几百条消息。

Canary第二阶段

第二个主要问题是我们的一个canary阶段,但是该阶段最多只能部署到GitHub.com流量的2%。这意味着在我们实现100%的生产之前,这一阶段还有很多问题没被发现,然后不得不开始事件并进行卷回恢复。可用性和正常运行时间是GitHub最为关注的问题,因此,随着GitHub的持续发展,这一风险对于修复和解决这一问题变得至关重要。考虑到这一点,我们开始以更高的百分比引入第二个Canary阶段,以便我们可以在早期阶段捕获更多问题,从而减少对未来事件的影响。

在该项目结束时,我们有两个canary阶段。第一个阶段在生产进度的2%,旨在抓住大多数问题。低百分比使风险状况保持在可容忍的水平,尽管少量的流量实际上会受到问题的影响。第二个canary阶段在生产进度的20%,使我们在仍处于canary阶段的情况下可以吸引更多的流量。这有较高的风险,但最初的2%canary阶段已减轻了风险,所以我们可以以较低的风险过渡到100%生产阶段。

自动化

最后一个问题是,开发人员必须坐下来进行部署,并通过运行独立的chatops命令来排队、部署canary和生产,从而在整个过程的各个步骤中来判断下一步。这意味着开发人员在每次部署中都会多次摸索chatops命令,但总是频频出错。

我们问自己“如何立刻执行刚下达命令?”。我们做到了这一点,实现了整个过程自动化。

解决方案

我们已经拥有内部部署软件,该软件能够跟踪部署的单个部分。该系统具有可靠的跟踪记录和坚实的基础,我们旨在增加从单个chatops命令自动化整个部署序列的能力,而不是每个部署都运行多个命令,并将这些记录链接到现有部署基础架构中。而且,这个新的解决方案将提供便于使用的界面,以快速概述任何给定的部署,而不是将多个chatops命令拼凑在一起。

我们提出了两个基本概念:

  1. 部署由许多阶段(canary,生产等)组成
  2. 在不同阶段之间存在关卡,它们执行某种检查以验证我们可以进行下一阶段

这些概念使我们能够以类似于状态机的方式对整个系统进行建模:

此图显示了2%canary、20%canary、生产部署和准备合并阶段之间的自动进度-由5分钟自动计时器分隔。最后,在计时器关卡完成并部署完阶段之后,指针将自动在整个数据模型中前进。

结果带来了具有第一方UI组件的状态机支持的部署系统,这结合了我们的开发人员已经熟悉的传统chatop。下面,你会看到最近已部署到GitHub.com的部署的概述。你可以转到统一的UI,而不是在嘈杂的Slack频道中跟踪各种消息。你可以在右侧的概述中看到上面提到的状态机进程。

深入研究特定部署,你可以看到特定部署期间发生的所有事情。你可以看到此部署的每个阶段之间都有一个自动5分钟的计时器,并且可以暂停部署让开发人员有更多时间进行测试。我们还确保在出现问题的情况下,可以通过右上角的下拉菜单来快速回滚或还原更改。

最后,整个系统可以像以前一样从Slack进行监视和启动。我们发现这就是开发人员通常想要开始其部署、然后在UI组件中进行监视的方式:

总结

这些变化彻底改变了我们部署GitHub.com的方式。曾经充满困惑的地方,现在使用自动化系统就能让我们感到高兴和满足。我们内部收到了大量的积极反馈,甚至引起了我们自己的Actions团队的关注。在这种情况下,我们的学习有助于影响GitHub Universe上发布的最新GitHub Actions CD产品中的决策。我们专注于我们自己的开发人员,这意味着我们可以运用我们的经验,继续为全球56M +开发人员创建最佳的系统。

如果没有各位和团队的奉献和工作,我们去年夏天的工作是不可能完成的。我们想向GitHub内部部署团队大声呼喊:他们现有的系统、建议和持续的帮助对于确保我们的部署成功至关重要。

构建 GitHub的博客系列

原文作者 Julian Nadeau

原文链接 https://github.blog/2021-01-25-improving-how-we-deploy-github/

推荐阅读
相关专栏
开源技术
106 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和声网 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。