基于 GitHub 的数据库 CI/CD 最佳实践

数据库变更一直是整个应用发布过程中效率最低、流程最复杂、风险最高的环节，也是 DevOps 流程中最难以攻克的阵地。那我们是否能在具体的 CI/CD 流程中，像处理代码那样处理数据库变更呢？

DORA 调研报告

DORA（DevOps Research & Assessment）是一家专注于 DevOps 的研究机构， 在该领域以专业与客观著称。自 2014 年以来，DevOps 调研了全球范围内超过 32,000 名专业人员，并以年度报告的形式对外发布研究成果。DORA 明确指出，将数据库变更纳入应用发布流程将显著提升整体发布效率。

这一结论并不令人意外。问题是，该怎么做？

Database DevOps 的关键要素

要回答「该怎么做」的问题，我们首先需要梳理数据库变更的完整过程，这可以被简单划分为两个步骤：SQL 审核 & SQL 发布。

SQL 审核

主要包括：

• 该变更正确实现了业务逻辑，即业务正确；
• 该变更不会引起潜在的数据库性能、安全、可用性、可管理性等问题，即架构正确。

在 SQL 审核步骤，开发团队一般负责「业务正确」，DBA 团队一般负责「架构正确」。由于两个团队多数时候是各自独立的，流程割裂也就成了必然。DevOps 理念期望通过将 Ops 与 Dev 融合来解决此类问题。当组织中拥有 DBA 角色时，我们很难快速将两个团队直接合并，也不能激进的将所有责任丢给开发团队，一种可行的策略是，在保留 DBA「架构正确」审核流程的同时，将相关能力前置到开发团队进行预审核，这样可以明显降低正式审核不通过导致的发布延迟几率。而如果组织中缺乏 DBA 类角色，对开发团队进行「架构正确」审核能力赋能则变得尤为重要。

SQL 发布

主要包括：

• 语句可以被正确执行。
  常见问题如连接错误的库、权限不足、对象名冲突、语法错误等；

• 语句执行没有遗漏。
  如果需要执行的脚本较多，或是面对多库批量执行，多环境流水发布的情况，都可能产生遗漏。

• 语句执行过程不影响业务。
  常见问题如硬件资源耗尽、长时间锁表等。

避免语句执行错误除了做好前述的审核工作，更关键的在于减少人工环节。无数的惨痛教训让我们认识到，越多的人工环节，误操作的几率越大。SQL 语句的执行过程应该尽可能引入自动化流程，通过预先配置的流水线，让通过审核的语句自动的应用到目标数据库中。而为了不让变更影响到业务的正常运行，各类零停机变更技术应该被广泛采用，特别是针对数据量庞大的库。

基于上述分析，我们可以总结出落地 Database DevOps 的两个关键要素：

1. 将 SQL 审核能力前置到开发团队；

2. 自动化的变更发布。

VCS 集成的 SQL 审核

我们首先探讨如何将 SQL 审核能力前置到开发团队。

绝大多数开发团队人员并不具备「架构正确」的 SQL 审核能力，即便是资深的 DBA，依赖人工进行逐句审核也是极为低效易错的。幸运的是，业界已经诞生多种自动化审核辅助工具，通过集成各类 SQL 规范，实现了对 SQL 语句的自动审核。

然而此类工具有一个共同的特点 —— 他们都是面向 DBA 设计。一方面，面向 DBA 的工具往往集成了较多 DBA 管理功能，对数据库拥有较高的操作权限，因此并不适合直接开放给广大开发人员使用。另一方面，开发团队日常有自己的工作界面，一个独立的外部审核工具带来的更多是效率的降低，想象一下，当你需要在多个工具间反复复制粘贴代码，这种体验该有多糟糕。

那么，什么样的赋能方式才符合开发者的工作习惯呢？

开发团队日常的应用代码审核流程是在版本控制系统（VCS）上进行，同理 SQL 语句也应该如此。因此，自动化的 SQL 审核工具在满足基本审核能力的同时，更关键的是将能力融入以 GitHub 为代表的 VCS 工作界面与流程中。Bytebase 作为一个面向开发团队设计的 Database DevOps 工具，充分考虑到了这一场景，通过将审核能力集成为 GitHub Actions (https://github.com/marketplace/actions/sql-review)，现在我们的开发人员可以在 GitHub 中审核 SQL 了。

Bytebase 已经上架 GitHub Marketplace

VCS 集成的 SQL 发布

我们再来探讨自动化的变更发布该如何实现。

独立的 SQL 部署工具同样并不鲜见。此类工具一般是先手动上传 SQL 脚本，通过审批流后执行部署，执行完成后再向相关方反馈结果。这种模式恰恰正是开发团队与 DBA 团队各自独立管理的具体表现，割裂的流程也是造成发布延迟的常见原因之一，例如由于遗忘了提交部分 SQL 脚本导致应用发布失败，毕竟不断的在多个系统间手动搬运代码，谁又能保证永远不出错呢？

我们需要寻找一种更高效的发布模式。让我们回忆一下应用代码的 CI/CD 工作流：提交变更 > 代码审核 > 分支合并 > 自动构建 > 自动部署，这一经典的流程实现了审核即发布，极大提升了发布效率。既然我们已经实现了在 GitHub 上审核 SQL，为什么不能将后续的执行过程也纳入进来呢？

是的，我们可以！

Bytebase 提供了另一项能力，与 VCS 集成的 SQL 发布。当我们的 SQL 脚本通过了审核并且合并入了目标分支，即可触发发布流程。相关脚本将被自动推送到 Bytebase 工具并生成对应工单，DBA 核准后即可自动应用到目标数据库中。

GitHub SQL repo

Bytebase VCS Integration Issue View

一个完整的 Database CI/CD 流程

通过 Bytebase，我们将实现一个完整的 Database CI/CD 工作流：

1. 开发者将变更 SQL 脚本提交到代码分支；
2. 触发 Bytebase 提供的 SQL Review Action 进行自动化 SQL 审核，并给出修改建议；
3. 修改完成后的 SQL 脚本合并入主分支；
4. 自动触发发布流程，脚本将被推送到 Bytebase 工具中；
5. DBA 或其他审核者利用 Bytebase 内置的自动审核能力对变更语句进行二次确认；
6. 核准后的语句自动在目标库中执行；
7. 变更完成后的数据库最新 Schema 结构将被自动回写入代码仓库；

8. 确认变更完成后，触发下一阶段的应用发布流程。

有经验的开发者一定联想到了生产环境的复杂性。

如果有大量数据库要批量变更怎么办？

如果有多个环境要实现流水发布怎么办？

如果多个开发者同时提交脚本怎么办？

......

请关注 Bytebase 后续文章，Bytebase 将从最基础的配置流程开始，一步步带您走进 Database DevOps 的世界。🌍