查看原文
其他

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

cy Bytebase 2022-12-19

数据库变更一直是整个应用发布过程中效率最低、流程最复杂、风险最高的环节,也是 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 的世界。🌍

Bytebase 招聘开发者关系 & 市场实习生

Rewind the PlanetScale Rewind | 拆解硅谷当红科技公司如何做 Product Marketing‍

基于 gh-ost 的在线 Schema 变更
我们还需要 SRE 吗?

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存