写点什么

使用 Ruby on Rails 构建 GitHub,每周做一次升级

  • 2023-09-25
    北京
  • 本文字数:2236 字

    阅读完需:约 7 分钟

大小:1.15M时长:06:43
使用 Ruby on Rails 构建 GitHub,每周做一次升级

本文介绍了 GitHub 如何使用 Ruby on Rails 构建他们的应用程序,并且每周如何进行升级。文章中提到 GitHub 与社区合作来确保每个 Rails 发布版本在生产环境中运行,并强调了投资于 Rails 的重要性。


自从成立以来,GitHub.com 一直是一个基于 Ruby on Rails 的单体应用。如今,该应用已经接近两百万行代码,每天有超过一千名工程师在上面协作。我们平均每天部署 20 次,几乎每周都会进行一次 Rails 的升级。


每周升级 Rails


每个周一,我们都会自动触发一个计划好的 GitHub Action 工作流,创建一个拉取请求,将我们的 Rails 版本更新到当天 Rails 主干分支的最新提交。我们所有的构建都在这个新版本的 Rails 上运行。一旦所有构建通过,我们会审核这些更改,并在第二天发布。从周一开始升级,用户就已经有一个打开的拉取请求,链接到此次 Rails 升级提出的更改和一个已经完成的构建。


这个过程与几年前我们进行 Rails 升级的方法大不相同。过去,我们花费数月的时间从自定义的 Rails 分支迁移到更新的稳定版本,然后我们维护了两个 Gemfiles,以确保我们能够与即将发布的版本兼容。现在,升级只需要不到一周的时间。(可以在这篇 2018 年的博文中了解更多有关此过程的信息。)我们与社区密切合作,确保每个 Rails 发布版本在正式发布之前都在生产环境中运行。


使用最新版本的 Rails 有很多实际的好处:


  • 我们为 GitHub 的开发人员提供最新版本的 Rails,确保他们可以使用所有最新的改进,包括更好的数据库连接处理、更快的视图渲染以及每天在 Rails 中发生的惊人工作,为他们提供最佳的工具版本

  • 我们已经几乎删除了所有的 Rails 补丁。由于我们正在运行最新版本的 Rails,开发人员现在可以直接提交补丁到 Rails,无需等待 Rails 的更改。

  • 与团队共享 Rails 工作现在比以往任何时候都更容易!你不需要再告诉团队你在下一版中发现的 Rails 问题,而是可以在 Rails 上直接工作并在下周就看到结果!

  • 保持最新的依赖关系可以使我们拥有更好的安全姿态。由于我们每周进行升级,所以在出现安全咨询时添加升级是标准做法,不需要额外的工作。

  • 没有所谓的“大爆炸”迁移。由于每个 Rails 升级只包含少量更改,如果有不兼容性,更容易理解和深入挖掘。从一个未知的位置出现的意外更改是来自困难升级的最糟糕的问题。这种升级策略可以减轻这些问题。

  • 在主干分支中捕获错误并做出贡献可以加强我们的工程团队,并帮助我们的开发人员深入了解我们的应用程序及其依赖项。

持续测试 Ruby


为了确保应用在最新的 Ruby 版本上运行良好,我们采用了持续测试的方法。在 2022 年 2 月,我们升级到 Ruby 3.1,并开始使用并行构建来测试从 3.2-alpha 版本提交的 Ruby shas。当 CI 运行 GitHub Rails 应用程序时,会运行两个版本的构建:一个版本使用我们在生产环境中运行的 Ruby 版本进行构建,另一个版本则使用包括最新 Ruby 更改的最新 Ruby 提交进行构建。我们每周更新一次。


尽管我们每次更改都会构建 Ruby,但 GitHub 只会发布经过编号的 Ruby 版本到生产环境。这些构建帮助我们保持与即将到来的 Ruby 版本的兼容性,并为我们提供关于 Ruby 更改的见解。


2022 年 12 月初,CI 让我们有了信心,认为我们与即将发布的 Ruby 3.2 兼容。因此,我们可以使用部分生产流量测试 Ruby 发布候选版,并向 Ruby 团队提供我们发现的任何更改的见解。例如,我们可以复现由于关键字参数处理引起的分配增加问题,并在 Ruby 3.2 发布之前得到修复。此外,我们还确定了在应用 to_str#to_i 时的微妙变化。由于我们不断升级,识别和解决这些问题已经成为标准惯例。


每周升级 Ruby 的过程使我们能够在一个月内从 Ruby 3.1 升级到 Ruby 3.2 的单体架构,毕竟,我们已经在生产中测试和运行过 Ruby 3.2!这是我们迄今为止完成的最快的 Ruby 升级。我们在 Ruby 3.2.1 发布当天打破了这个记录。


这个升级过程对我们与 Ruby 核心团队的合作证明非常宝贵。拥有这些构建的一个好的附带效果是,我们能够轻松地测试和分析我们自己的 Ruby 更改,然后再向上游建议。这使我们更容易识别我们自己应用程序中的回归,并更好地理解更改对生产环境的影响。

我也应该这么做吗?


GitHub 之所以能够频繁升级 Ruby 和 Rails,是因为具备了一定的工程成熟度。每周升级 Rails 需要一个全面的测试套件,许多优秀的工程师致力于维护和改进它。此外,我们还从拥有出色的测试环境和渐进式部署中获得信心。我们的测试套件很可能会捕捉到问题,如果没有,我们相信在部署之前会发现并解决它。


如果你拥有这些工具,你也应该每周升级 Rails,并使用最新的 Ruby 进行测试。GitHub 成为了更好的 Rails 应用程序,这使我们的团队能够进行我非常自豪的工作。


Ruby 专家 Eileen Uchitelle 在 2022 年的 Rails Conf Keynote 中解释了为什么投资于 Rails 很重要:


归根结底,如果更多公司将框架视为应用程序的扩展,这将导致更高的韧性和稳定性。投资于 Rails 可确保您的基础不会在应用程序的重压下崩溃。将其视为应用程序中不重要的部分是一个错误,许多领导者都犯了这个错误。


感谢来自全世界的人们的贡献,使用 Ruby 比以往任何时候都更好。GitHub 和其他数百家公司一样,受益于 Ruby 和 Rails 不断改进。定期升级和投资于我们的框架是我们在 GitHub Ruby 架构团队上的工作的核心。我们始终感激 Ruby 社区,并很高兴我们能以一种改进我们的应用程序和工具以及为每个人改进它们的方式回馈。


作者介绍

Adam Hess,软件开发者。


原文链接:

https://github.blog/2023-04-06-building-github-with-ruby-and-rails/

2023-09-25 12:068368

评论

发布
暂无评论
发现更多内容

软件即服务 与生态伙伴发展共赢 英特尔原来身负重任

E科讯

使用基于 tideways 的 php-monitor 搭建 PHP 性能监控平台

菜皮日记

php

MongoDB 官方文档笔记之索引 Indexes

菜皮日记

mongodb

MongoDB 官方文档笔记之分片 Sharding

菜皮日记

mongodb

结构型设计模式-代理 Proxy

菜皮日记

设计模式

行为型设计模式-责任链 Chain Of Responsibility

菜皮日记

设计模式

MongoDB 官方文档笔记之存储 Storage

菜皮日记

mongodb

tornado 的协程调度原理

菜皮日记

tornado

PHP Composer 的自动加载

菜皮日记

php composer

Java 中反射、注解、动态代理、AOP 之间的联系

菜皮日记

Java aop

PHP7内核实现原理-基本环境和C基础

菜皮日记

php

行为型设计模式-中介者 Mediator

菜皮日记

设计模式

行为型设计模式-状态 State

菜皮日记

设计模式

2020 年书单

菜皮日记

读书笔记

京沪永远涨是否会涨到永远 - 读《菜场经济学》

菜皮日记

读书笔记

好奇是开启智慧的钥匙 - 读《朝闻道》

菜皮日记

读书笔记

MongoDB 官方文档笔记之复制 Replication

菜皮日记

mongodb

行为型设计模式-命令 Command

菜皮日记

设计模式

行为型设计模式-迭代器 Iterator

菜皮日记

设计模式

行为型设计模式-观察者(发布订阅) Observer

菜皮日记

设计模式

行为型设计模式-备忘录 Memento

菜皮日记

设计模式

结构型设计模式-桥接(模块化) Bridge

菜皮日记

设计模式

结构型设计模式-享元(缓存)Flyweight

菜皮日记

设计模式

行为型设计模式-访问器 Visitor

菜皮日记

设计模式

Java 动态代理原理

菜皮日记

Java 动态代理

结构型设计模式-组合(对象树) Composite

菜皮日记

设计模式

结构型设计模式-装饰器 Decorator

菜皮日记

设计模式

行为型设计模式-策略 Strategy

菜皮日记

设计模式

前辈从业多年的心得分享 - 读《这就是软件工程师》

菜皮日记

读书笔记

结构型设计模式-外观 Facade

菜皮日记

设计模式

行为型设计模式-模板方法 Template Method

菜皮日记

设计模式

使用 Ruby on Rails 构建 GitHub,每周做一次升级_架构_Adam Hess_InfoQ精选文章