数据库改变一直是整个使用发布进程中功率最低、流程最复杂、风险最高的环节,也是 DevOps 流程中最难以霸占的阵地。那咱们是否能在详细的 CI/CD 流程中,像处理代码那样处理数据库改变呢?

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

DORA 调研陈述

DORA(DevOps Research & Assessment)是一家专注于 DevOps 的研究机构, 在该范畴以专业与客观著称。自 2014 年以来,DevOps 调研了全球范围内超越 32,000 名专业人员,并以年度陈述的形式对外发布研究成果。DORA 明确指出,将数据库改变归入使用发布流程将明显提高整体发布功率

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

这必定论并不令人意外。问题是,该怎么做?

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 东西,充分考虑到了这一场景,经过将审阅才能集成为SQL Review GitHub Actions,现在咱们的开发人员能够在 GitHub 中审阅 SQL 了。

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

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

咱们再来讨论主动化的改变发布该如何完成

独立的 SQL 布置东西同样并不鲜见。此类东西一般是先手动上传 SQL 脚本,经过审批流后履行布置,履行完成后再向相关方反应成果。这种模式恰恰正是开发团队与 DBA 团队各自独立管理的详细表现,分裂的流程也是形成发布延迟的常见原因之一,例如因为遗忘了提交部分 SQL 脚本导致使用发布失利,究竟不断的在多个体系间手动搬运代码,谁又能保证永远不犯错呢?

咱们需求寻找一种更高效的发布模式。让咱们回忆一下使用代码的 CI/CD 作业流:提交改变 > 代码审阅 > 分支兼并 > 主动构建 > 主动布置,这一经典的流程完成了审阅即发布,极大提高了发布功率。既然咱们现已完成了在 GitHub 上审阅 SQL,为什么不能将后续的履行进程也归入进来呢?

是的,咱们能够!

Bytebase 供给了另一项才能,与 VCS 集成的 SQL 发布。当咱们的 SQL 脚本经过了审阅并且兼并入了方针分支,即可触发发布流程。相关脚本将被主动推送到 Bytebase 东西并生成对应工单,DBA 核准后即可主动使用到方针数据库中。

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

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

完好的 Database CI/CD 流程

基于 GitHub 的数据库 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 的世界。