GitHub 针对开发者在其平台上频繁执行的代码推送操作推出了一系列技术革新，旨在提升操作的稳定性与效率。这些升级措施不仅解决了潜在的技术问题，还为定期向 GitHub 推送代码的用户提供更流畅的体验。
GitHub 的一位软件工程师 William Haltom 详细阐述了这次技术升级的背景。Haltom 首先分享了向 GitHub 推送代码会触发一系列动作，例如同步拉取请求、分发 Webhook、触发工作流、安装应用、发布 GitHub Pages 以及更新 Codespaces 配置。此外，每次推送还会激活 GitHub 内部的 60 多个流程，这些流程为开发者提供了不同的特性和自动化工具。
在过去，GitHub 依赖一个叫作 RepositoryPushJob 的大型单体后台作业来处理所有由代码推送触发的动作。这个作业在 GitHub 的 Ruby on Rails 单体应用中，按顺序执行所有的推送处理逻辑。然而，由于作业的规模庞大且复杂，导致了一些问题。在作业内重试个别任务非常困难，而且大多数步骤根本没有进行重试。
缺乏可靠的重试机制意味着作业早期阶段的错误可能会产生连锁反应，影响后续的步骤，从而引发一系列的潜在问题。
我们如何改进 GitHub 的推送处理逻辑
GitHub 对其代码推送流程进行了彻底的改革，将原本漫长且顺序执行的作业分解为多个独立且并行运行的流程。为此，他们创建了一个新的 Kafka 主题用于广播推送事件。根据任务所归属的服务或逻辑关系——例如它们之间的依赖关系和重试需求——对众多的推送处理任务进行了细致的分析和分类。
每个任务组都重新分配到了一个新的后台作业中，这个作业有明确的所有者和适当的重试机制。然后，这些作业被配置成可以响应由新的 Kafka 事件所触发的信号。
为了支持这种架构，GitHub 使用了一个内部系统来响应 Kafka 事件并安排后台作业的队列。包括开发 Kafka 事件的可靠发布者、设置专用的工作池来管理增加的作业数量、增强可观测性以监控推送事件流，以及建立一致的特性标志系统，以确保新系统的安全发布。
我们如何改进 GitHub 的推送处理逻辑
GitHub 最近在 GitHub Actions 中引入对 Arm64 的支持，为开发者提供了在 Arm 架构上发布软件的 Arm 构建的镜像，这则消息在技术社区 Hacker News 上引发了广泛的讨论。一位 GitHub 和 Hacker News 的用户 Obviyus 表示他对加入对 Arm64 的支持感到非常兴奋，他们之前一直依赖自托管的 Arm 运行器来进行项目开发。他指出，在他们的小型 Arm VPS 上编译代码可能会显著地拖慢其他任务的运行速度。为此，他对官方提供对 Arm64 的支持表示热烈欢迎，认为这是一个迫切需要的改进。
今年早些时候，Hacker News 上的一篇帖子还讨论了 Copilot Workspace，这是一项创新工具，旨在简化开发流程，允许开发者使用自然语言进行头脑风暴、规划、编码、测试和项目执行。
Haltom 进一步解释了架构改革的结果，他指出，将原本庞大的流程拆解为更小、更独立的部分，问题的影响范围得到了有效控制。推送处理逻辑中某一部分的问题不再会引起连锁反应，影响到其他部分，从而提高了稳定性和可靠性。此外，这种解耦也减少了各个部分之间的依赖性。
此外，新架构还明确了所有权，将推送处理代码的责任分配给了超过 15 个服务的所有者。这样的分配机制使得各个团队能够在不引发意外后果的前提下添加和迭代推送功能。最后，由于作业的规模更小、复杂度降低，整个推送处理过程变得更加可靠。
原文链接：
https://www.infoq.com/news/2024/06/github-push-process-enhancement/
