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

数据库更改是开发过程中一个棘手的部分。我们能否像对待代码一样对待数据库，将其作为 CI/CD 周期的一部分？
数据库更改是应用程序开发过程中一个棘手的部分：它通常涉及来自不同环境的多个数据库和跨团队协作，此外，数据库是一触即发的。它让我们思考：我们可以像对待应用程序代码一样对待数据库吗？
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 审查，为什么不能包括后续的推出流程呢？
嗯，是的，我们可以！
【GitHub 的数据库 CI/CD 最佳实践】用于数据库 CI/CD 的 SQL 更改推出工具应该能够与 VCS 集成。一旦您的 SQL 脚本经过审查并合并到目标分支中，就会触发发布过程，并且脚本会自动推送到 Bytebase 。当然，DBA 可以在针对目标数据库执行 SQL 之前执行另一次完整性检查。