终章｜Database CI/CD with GitHub 教程 ③

今天，Database CI/CD with GitHub 教程系列的最后一部分：终章，将引导你把 GitOps 工作流和 SQL Review Actions 联结起来，完成 Database CI/CD 的整个过程。

问题：既然我们可以直接在 Bytebase 中配置 SQL 审核（UI 工作流），为什么还需要在 GitHub 中配置 SQL Review Actions？

在现实场景中，代码审核通常是由 Tech Leader 完成的，也包括 SQL的审核，为的是确保该变更正确实现了业务逻辑，即业务正确；而 DBA 负责审核 SQL则是为了变更不会引起潜在的数据库性能、安全、可用性、可管理性等问题，即架构正确。这两方会在不同阶段使用 SQL 审核工具。

如何做到这一点，从而真正实现数据库 CI/CD 呢？具体的配置在前两篇教程中：开启 SQL Review Actions & 实现数据库 GitOps 已经详细介绍过了，本教程将把前两部分合二为一，带你真正走进数据库 CI/CD 的世界 🌍。

Step 1. 为 prod 环境添加配置文件 

根据开启 SQL Review Actions 教程来配置你的 prod 环境，现在你有两个 GitHub Actions 的配置文件。请特别注意文件路径 (path) 和命名模式 (file-pattern)。

Step 2. 创建新 PR 并添加 SQL 脚本

在 GitHub 仓库下建立一个新的分支（此教程叫做 testboth ）。

按照以下命名规范，在 bytebase/test 文件夹下添加你的 SQL 脚本👇。

{ENV_NAME}}/{{DB_NAME}}__{{VERSION}}__{{TYPE}}__{{DESCRIPTION}}.sql

比如，这里叫做 employeeGitHub__202208211500__migrate__add_nickname.sql 。

把脚本提交并推送到 testboth 分支，并在 GitHub 上创建一个 PR。SQL Review Actions 将被自动触发。执行完成后，你就可以把 PR 合并到主分支了。

PR 合并到主分支后，Bytebase 会自动建立一个新的 Issue。

点击 Approve 来批准执行此 SQL 脚本，它将针对 test 环境运行。

当 Issue 状态变成 Done 时，一个命名规范是 xx__LATEST.sql 的文件将自动生成，记录了数据库的当前状态（此教程为 .employeeGitHub__LATEST.sql）。

如果在 test 环境中一切正常，你就可以复制你的 SQL 脚本（⚠️除了 xx__LATEST.sql ）并粘贴到 prod 文件夹下，以触发 prod 环境的 schema 变化。Good Luck!

总结一下

来总结一下完整的步骤：

1. 在你的本地分支上添加一个 SQL 脚本，推送它至 GitHub 并创建一个 PR；

2. 配置好的 SQL Review Actions 被自动触发运行；

3. 如果 SQL 审核无误，你就可以把它合并到主分支中；

4. 触发在 Bytebase 创建一个 Issue；

5. SQL Review 审核将再次在该脚本上运行；

6. 审核完成且手动批准后，SQL 脚本将在你的数据库上运行，完成后，代表变更成功；

7. Bytebase 将最新数据库 schema 写回到你的 GitHub 仓库；

8. 所有变更工作都完成后，你可以部署依赖于新 schema 的应用程序代码了。

🎉 Congrats

祝贺！你已经成功通过 Bytebase 实现了基于 GitHub 的完整 Database CI/CD 流程，步入了数据库的 DevOps 世界 🌏。

欢迎加入我们的用户群来一起交流使用体验！🍉