工程团队的开发速度是 PlanetScale 的首要任务之一，无论是对我们自己的团队，还是对所有使用我们构建的工具的开发者而言。

在构建 PlanetScale 时，我们的早期目标之一就是为工程团队打造绝对最佳的模式变更流程。过去 3 年里我们一直在迭代优化，对于如今更改应用程序模式的便捷程度，我们越来越感到满意。

我们的主 API（应用程序编程接口） 是一个 Ruby on Rails 应用程序，连接了两个 PlanetScale 数据库。其中一个数据库包含我们大部分的业务和用户数据。另一个是更大的分片数据库，用于处理支撑 PlanetScale Insights 所需的大规模负载。

我们的团队几乎每天都会对这些数据库进行模式变更。我们使用的是与为客户构建的完全相同的工具。此外还加入了我们自己的“GitHub Actions Bot”，用于自动化 Rails 应用程序特有的步骤。在本文中，我将分享 PlanetScale 当前进行模式变更的流程。

生产数据库模式变更

世界上大多数 Rails 应用程序在每次部署时更新其生产模式。它们会在 CI 流程中、部署代码到生产环境之前立即运行 rails db:migrate。这个流程对许多团队来说运行良好，但随着数据量和工程团队规模的增长，往往会遭遇成长的烦恼。

我们观察到两个主要问题：

• 随着数据量增长，直接对生产环境运行模式变更（DDL）变得越来越危险和耗时。

• 频繁部署的大型团队会因彼此的模式变更而受阻，并承受更高的协调成本。

痛苦的迁移流程代价很高。对于这些问题最严重的团队，工程师会开始寻找避免进行模式变更的方法。要么以不同的方式设计功能，要么滥用 json 列而不是采用合理的模式设计。

修复流程：解决方案的起点是切断模式迁移与代码之间的绑定关系。让两者可以独立发布。这样做有很多好处。最大的好处是：工程师现在被迫更深入地思考他们的代码和数据库模式变更如何相互作用。

修复流程的下一步是引入在线 schema 变更工具。

在线 schema 变更

“在线”是数据库领域用来描述无需停机的变更的术语。Rails 社区在构建工具和普及如何在不中断服务的情况下完成迁移方面做得非常出色。我认识的每一位 Rails 开发者都记住了哪些 schema 变更可能导致锁表。甚至还有一些 gem 可以引导我们安全地进行变更。

即使有这些教育和工具，如果没有数据库层面的解决方案，问题仍然无法完全解决。

许多应用开发者并不知道，“大规模”公司已经构建了一整套工具来处理这个问题。这些工具被称为在线 schema 变更工具。它们替代了 rails db:migrate，并以不会中断数据库生产流量的方式运行 schema 变更。这样做的好处是，应用开发者不再需要跟踪哪些 schema 变更可能导致表锁定。schema 变更工具将以始终安全的方式进行变更，从而减轻了围绕 schema 变更的许多恐惧。

你能想到的大多数大型公司都在使用各种在线 schema 变更工具来进行迁移。

在 PlanetScale，维护 Vitess 在线 schema 变更工具的团队就在我们的员工之中。这也通过我们的安全迁移功能直接内置于 PlanetScale 中。

应用代码与 schema 变更的时机配合

对于数据库中的每一次 schema 变更，考虑应用层将如何处理该变更也至关重要。我们可以拥有现存最好的 schema 变更工具，但如果我们在应用与数据库交互的方式上犯错，停机仍然可能发生。

我们在开发者中常见的一个误解是，他们认为可以同时原子性地部署 schema 和应用代码。这是不可能的。对于每一次 schema 变更，应用都需要被设置为能够同时处理当前和未来的 schema。如果不这样做，错误就会接踵而至。

每家公司理想的工作流程都涉及数据库层面和应用层面的解决方案。

我们的 schema 变更工作流程

当 PlanetScale 的开发者进行 schema 变更时，流程从本地开始。应用程序代码在 git 分支中修改，任何相应的数据库 schema 变更都会在本地 MySQL 实例中应用。本地开发和测试完成后，他们提交更改并在 GitHub 上打开 pull request。

Pull request 机器人

我们使用 GitHub Actions 构建了一个“pull request 机器人”，它会检测 pull request 中需要进行的任何 schema 变更。当它看到变更时，会创建一个 PlanetScale 分支，运行迁移，打开一个 deploy request（PlanetScale 进行 schema 变更的方法），并在 GitHub 中评论结果。

关于此工作流的几点说明：

• 我们仅在存在 schema 变更时创建 PlanetScale 分支

• 我们的 CI 针对本地 MySQL 运行以获得最低延迟

• 我们使用 planetscale_rails gem 来运行迁移

这些步骤因应用程序而异，但总体流程是相似的。

通过我们的机器人，我们能够使用 PlanetScale API 来检测对数据库所做的变更类别。然后，机器人根据变更的特征生成评论，包括为我们的应用程序安全进行变更所需的步骤序列说明。每个应用程序都不同，但在进行 schema 变更时，它们都有相似的需求。

• 删除列时，必须在更改 schema 之前部署应用程序代码

• 添加列时，必须在更改 schema 之后部署应用程序代码 注意 要深入了解此模式的工作原理，请查看我们的向后兼容数据库变更博客文章。

Deploy request

机器人会自动为我们打开一个 deploy request，并留下一条链接到 GitHub 中变更的评论。这使我们的团队能够同时审查 schema 变更和代码。提供关于变更原因和内容的完整上下文。

在 schema 变更部署之前，会通过 linter 运行检查以捕获任何常见错误。

deploy request 将使用 Vitess 在线迁移进行 schema 变更。这保护了生产环境，也允许我们在发现任何问题时快速回滚 schema 变更。

当多个团队成员同时进行 schema 变更时，PlanetScale 会为每个变更创建一个队列。这使得每个变更可以按照加入队列的顺序自动部署。这同样具有安全方面的优势，PlanetScale 不仅对每个 schema 变更运行安全检查，还会对所有变更合并后的最终数据库 schema 运行安全检查。这在多人同时进行变更时可以有效防止错误。

我该如何实现这一点？

通过将我们的 GitHub Actions 机器人（bot）与 PlanetScale 部署请求（deploy requests）相结合，我们发现我们的 schema 变更流程非常令人满意。开发者能够快速进行变更，同时确信他们正在部署的变更不会影响生产环境。

该机器人将 PlanetScale 内置的在线 schema 变更工具与我们 Rails 应用程序的特定需求结合在一起。有了这些组合，开发者可以快速且自信地推进工作。

我们部署代码和 schema 的流程是刻意分开的，这迫使我们的工程师仔细思考变更的每一个步骤。同时也让我们能够快速推进，代码变更永远不会因为其他团队成员不相关的 schema 迁移而被阻塞。

我们使用 GitHub Actions 实现了我们的机器人，不过类似的工作流也可以通过其他 CI 工具来实现。在 PlanetScale 方面，所有需要的 API 调用都可以通过 pscale CLI 来完成。

我们已经在 GitHub Actions 文档页面 中发布了许多工作流的关键部分。通过这个页面，你可以混合搭配这些示例，以满足你的团队和应用程序的需求。

如果你有一个 Rails 应用程序，我们已经在 planetscale_rails readme 中直接发布了相关说明。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：PlanetScale Blog

原创地址：https://planetscale.com/blog/how-planetscale-makes-schema-changes