数据库更改是应用程序开发过程中一个棘手的部分：它通常涉及来自不同环境的多个数据库和跨团队协作，此外，数据库是一触即发的。它让我们思考：我们可以像对待应用程序代码一样对待数据库吗？
DORA（DevOps Research & Assessment）指出，将数据库工作整合到软件交付过程中，对持续交付有积极的贡献。是时候让数据库成为 CI/CD 周期的一部分了。
但它是如何工作的？
数据库 CI/CD 的关键要素
要回答“如何”，我们首先需要梳理一下典型的数据库变更工作流程。在 SQL 语句可以安全地应用于数据库之前，有两个关键步骤：review & change。
1. SQL 审查
此步骤是为了确保更改：
- 准确实现业务逻辑；
- 遵循数据库设计最佳实践；
在这里，开发人员通常负责前者的任务，而 DBA 则负责后者。DevOps 理念旨在通过集成 Ops 和 Devs 来解决这个问题。现实情况是，当组织中存在 DBA 时，很难将两个团队直接合并。一种可能的解决方案是保留 DBA 的任务，同时让开发团队能够预审 SQL。这种左移方法可以显着减少发布延迟的机会。此外，如果组织中没有 DBA，那么赋予开发团队以确保 SQL 不会对数据库造成严重破坏的能力就更加重要。
2、SQL变更执行
此步骤是为了确保：
- 语句正确执行。我们不希望出现错误的数据库连接、权限不足、对象名称冲突或基本语法错误。
- 所有计划的语句都被执行。当要执行的脚本很多或者有多个目标数据库要批量执行时，可能会出现遗漏。
- 变更执行过程不应影响业务。硬件资源耗尽和长时间锁定表对公司来说并不愉快。
为了避免与变更相关的错误，减少手动方面也很重要：自动化的事情越多，发生错误的机会就越少。预配置管道以自动将 SQL 应用于数据库？听起来不错。为避免对常规业务运营产生负面影响，应采用各种零停机更改技术，尤其是对于具有大型数据集的数据库。
因此，实施数据库 CI/CD 的关键要素应该使开发团队能够执行 SQL 审查并简化 SQL 更改推出。
使用 VCS 集成进行 SQL 审查和变更部署
让我们首先探讨如何让开发团队自己执行 SQL 审查。
很少有开发人员是审查 SQL 语句“架构正确性”的专家，即使对于高级 DBA，手动检查也可能非常低效且容易出错。幸运的是，业界通过集成不同的 SQL 检查规范创建了各种自动审查工具。
然而，这些工具有一个共同的问题——它们都是为 DBA 设计的。一方面，这些工具往往需要更高的数据库操作权限，因此不适合开发人员直接使用。另一方面，开发人员拥有自己的 IDE，而单独的外部仲裁器是他们最不需要的东西。想象一下，当您必须在多个工具之间复制和粘贴代码时会有多糟糕。
那么开发人员友好的 SQL 审查工具应该是什么样的呢？
我们通常在版本控制系统 (VCS) 上执行传统的代码审查流程，SQL 也应如此。因此，应该将 SQL 审查工具集成到代码审查工作流程中。启用后，当您在 GitHub 上提交 PR 时，将触发GitHub Marketplace 上可用的 SQL Review Action 。
让我们看看如何实现简化的 SQL 更改推出。
独立的 SQL 部署工具并不少见。这些工具通常手动上传 SQL 脚本，通过审批流程继续部署，然后在部署完成后提供反馈。该模型准确地描述了开发人员和 DBA 如何独立工作，而分散的流程是延迟发布的最常见原因之一。毕竟，当您在多个系统之间不断手动移动 SQL 脚本时，谁能保证永远不会出错？
我们需要一个更高效和自动化的发布流程。让我们回顾一下应用程序代码的经典 CI/CD 工作流程：提交更改 > 代码审查 > 合并分支 > 自动构建 > 自动部署。既然我们已经在 GitHub Actions 上实现了 SQL 审查，为什么不能包括后续的推出流程呢？
嗯，是的，我们可以！
用于数据库 CI/CD 的 SQL 更改推出工具应该能够与 VCS 集成。一旦您的 SQL 脚本经过审查并合并到目标分支中，就会触发发布过程，并且脚本会自动推送到 Bytebase。当然，DBA 可以在针对目标数据库执行 SQL 之前执行另一次完整性检查。
完整的数据库 CI/CD 工作流程
在这里，我们展示了一个完整的数据库 CI/CD 工作流程：
- 开发者创建一个包含 SQL 迁移脚本的 Merge Request / Pull Request；
- 自动触发 SQL Review Action 来审查 SQL 并提供建议以协助代码审查；
- 经过几次可能的迭代后，开发团队中的团队领导或其他同事批准更改并将 SQL 脚本合并到一个分支中；
- 合并事件自动触发 Bytebase 中的发布管道，并创建捕获预期更改的发布票；
- （可选）DBA 或指定的审阅者可以通过 Bytebase 的内置 UI 审阅更改脚本；
- 批准的脚本会根据配置的上线阶段逐步执行；
- 应用更改后，最新的数据库模式会自动写回代码存储库。这样一来，开发团队始终拥有最新架构的副本。此外，他们可以根据最新模式的变化配置下游管道；
- 确认迁移并继续进行相应的应用程序推出。
此工作流程非常适合现有的 CI/CD 流程，并且对开发人员来说很自然。敏锐的读者可能已经发现所描述的步骤是具有里程碑意义的文章Evolutionary Database Design的实现。