数据库改变一直是整个使用发布进程中功率最低、流程最复杂、风险最高的环节，也是 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 的两个关键要素：
- 将 SQL 审阅才能前置到开发团队；
- 主动化的改变发布。
VCS 集成的 SQL 审阅
咱们首要讨论如何将 SQL 审阅才能前置到开发团队。
绝大多数开发团队人员并不具有「架构正确」的 SQL 审阅才能，即便是资深的 DBA，依赖人工进行逐句审阅也是极为低效易错的。幸运的是，业界现已诞生多种主动化审阅辅助东西，经过集成各类 SQL 规范，完成了对 SQL 句子的主动审阅。然而此类东西有一个一起的特点 —— 他们都是面向 DBA 设计。一方面，面向 DBA 的东西往往集成了较多 DBA 管理功用，对数据库拥有较高的操作权限，因此并不合适直接开放给广大开发人员使用。另一方面，开发团队日常有自己的作业界面，一个独立的外部审阅东西带来的更多是功率的下降，想象一下，当你需求在多个东西间重复复制粘贴代码，这种体会该有多糟糕。
那么，什么样的赋能方式才符合开发者的作业习气呢？
开发团队日常的使用代码审阅流程是在版本控制体系（VCS）上进行，同理 SQL 句子也应该如此。因此，主动化的 SQL 审阅东西在满足根本审阅才能的一起，更关键的是将才能融入以 GitHub 为代表的 VCS 作业界面与流程中。Bytebase 作为一个面向开发团队设计的 Database DevOps 东西，充分考虑到了这一场景，经过将审阅才能集成为SQL Review GitHub Actions，现在咱们的开发人员能够在 GitHub 中审阅 SQL 了。
咱们再来讨论主动化的改变发布该如何完成。
独立的 SQL 布置东西同样并不鲜见。此类东西一般是先手动上传 SQL 脚本，经过审批流后履行布置，履行完成后再向相关方反应成果。这种模式恰恰正是开发团队与 DBA 团队各自独立管理的详细表现，分裂的流程也是形成发布延迟的常见原因之一，例如因为遗忘了提交部分 SQL 脚本导致使用发布失利，究竟不断的在多个体系间手动搬运代码，谁又能保证永远不犯错呢？
咱们需求寻找一种更高效的发布模式。让咱们回忆一下使用代码的 CI/CD 作业流：提交改变 > 代码审阅 > 分支兼并 > 主动构建 > 主动布置，这一经典的流程完成了审阅即发布，极大提高了发布功率。既然咱们现已完成了在 GitHub 上审阅 SQL，为什么不能将后续的履行进程也归入进来呢？
是的，咱们能够！
Bytebase 供给了另一项才能，与 VCS 集成的 SQL 发布。当咱们的 SQL 脚本经过了审阅并且兼并入了方针分支，即可触发发布流程。相关脚本将被主动推送到 Bytebase 东西并生成对应工单，DBA 核准后即可主动使用到方针数据库中。
完好的 Database CI/CD 流程
经过 Bytebase，咱们将完成一个完好的 Database CI/CD 作业流：
- 开发者将改变 SQL 脚本提交到代码分支；
- 触发 Bytebase 供给的 SQL Review Action 进行主动化 SQL 审阅，并给出修正主张；
- 修正完成后的 SQL 脚本兼并入主分支；
- 主动触发发布流程，脚本将被推送到 Bytebase 东西中；
- DBA 或其他审阅者使用 Bytebase 内置的主动审阅才能对改变句子进行二次承认；
- 核准后的句子主动在方针库中履行；
- 改变完成后的数据库最新 Schema 结构将被主动回写入代码仓库；
- 承认改变完成后，触发下一阶段的使用发布流程。
有经验的开发者必定联想到了生产环境的复杂性。
假如有很多数据库要批量改变怎么办？
假如有多个环境要完成流水发布怎么办？
假如多个开发者一起提交脚本怎么办？
……
请重视 Bytebase 后续文章，Bytebase 将从最根底的装备流程开端，一步步带您走进 Database DevOps 的世界。
