<返回更多

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

2022-09-03  网易号  qaseven
加入收藏

数据库更改是开发过程中一个棘手的部分。我们能否像对待代码一样对待数据库,将其作为 CI/CD 周期的一部分?

数据库更改是应用程序开发过程中一个棘手的部分:它通常涉及来自不同环境的多个数据库和跨团队协作,此外,数据库是一触即发的。它让我们思考:我们可以像对待应用程序代码一样对待数据库吗?

DORA(DevOps Research & Assessment)指出,将数据库工作整合到软件交付过程中,对持续交付有积极的贡献。是时候让数据库成为 CI/CD 周期的一部分了。

但它是如何工作的?

数据库 CI/CD 的关键要素

要回答“如何”,我们首先需要梳理一下典型的数据库变更工作流程。在 SQL 语句可以安全地应用于数据库之前,有两个关键步骤:review & change

1. SQL 审查

此步骤是为了确保更改:

 

  1. 准确实现业务逻辑;
  2. 遵循数据库设计最佳实践;

 

在这里,开发人员通常负责前者的任务,而 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 工作流程


 

 

  1. 开发者创建一个包含 SQL 迁移脚本的 Merge Request / Pull Request;
  2. 自动触发 SQL Review Action 来审查 SQL 并提供建议以协助代码审查;
  3. 经过几次可能的迭代后,开发团队中的团队领导或其他同事批准更改并将 SQL 脚本合并到一个分支中;
  4. 合并事件自动触发 Bytebase 中的发布管道,并创建捕获预期更改的发布票;
  5. (可选)DBA 或指定的审阅者可以通过 Bytebase 的内置 UI 审阅更改脚本;
  6. 批准的脚本会根据配置的上线阶段逐步执行;
  7. 应用更改后,最新的数据库模式会自动写回代码存储库。这样一来,开发团队始终拥有最新架构的副本。此外,他们可以根据最新模式的变化配置下游管道;
  8. 确认迁移并继续进行相应的应用程序推出。

 

此工作流程非常适合现有的 CI/CD 流程,并且对开发人员来说很自然。敏锐的读者可能已经发现所描述的步骤是具有里程碑意义的文章Evolutionary Database Design的实现。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>