数据库变更一直是整个应用发布过程中效率最低、流程最复杂、风险最高的环节，也是 DevOps 流程中最难以攻克的阵地。那我们是否能在具体的 CI/CD 流程中，像处理代码那样处理数据库变更呢？

DORA 调研报告

DORA（DevOps Research & Assessment）是一家专注于 DevOps 的研究机构， 在该领域以专业与客观著称。自 2014 年以来，DevOps 调研了全球范围内超过 32,000 名专业人员，并以年度报告的形式对外发布研究成果。DORA 明确指出，将数据库变更纳入应用发布流程将显著提升整体发布效率。

这一结论并不令人意外。问题是，该怎么做？

一个完整的基于 GitLab 的数据库 CI/CD 工作流

通过 Bytebase，我们将实现一个完整的基于 GitLab 的数据库 CI/CD 工作流：

1. 开发者将变更 SQL 脚本提交到代码分支；
2. 触发 Bytebase 提供的 SQL 审核 CI 进行自动化 SQL 审核，并给出修改建议；
3. 修改完成后的 SQL 脚本合并入主分支；
4. 自动触发发布流程，脚本将被推送到 Bytebase 工具中；
5. Bytebase 内置的自动审核将对变更语句进行二次确认，根据变更风险等级自动匹配审批流，根据审批流审批；
6. 审批后的语句可以通过手动或自动触发在目标库中执行；
7. 变更完成后的数据库最新 schema 结构将被自动回写入代码仓库；
8. 确认变更完成后，触发下一阶段的应用发布流程。

通过 Bytebase 社区版实现

让我们一步一步看看这个过程怎样实现的。

第一步 通过 Docker 启动 Bytebase，并配置外部 URL

ngrok 是一个反向代理工具，我们需要它的公网地址，以便从 GitHub 接收 webhooks。这里使用 ngrok 是出于测试目的；生产环境建议使用 Caddy。

1. 登录 ngrok Dashboard，并按照 Getting Started 步骤进行安装和配置。
2. 在 Docker 中运行 Bytebase： ``` docker run --init \

--name bytebase
--restart always
--publish 5678:8080
--health-cmd "curl --fail http://localhost:5678/healthz || exit 1"
--health-interval 5m
--health-timeout 60s
--volume ~/.bytebase/data:/var/opt/bytebase
bytebase/bytebase:2.8.0
--data /var/opt/bytebase
--port 8080

3. Bytebase 通过 Docker 成功启动，你可以通过 `localhost:5678` 来访问。注册一个管理员账号。
4. 在命令行运行 ngrok http 5678 ，并获得公共 URL。
![file](https://img-blog.csdnimg.cn/009fdddb447a428c939d4ce23f751487.png)
5. 登录 Bytebase，点击右上角的齿轮，将公共 URL 填入到网络部分的外部 URL，点击更新。### 第二步 在 Bytebase 种添加 GitLab.com 作为 Git Provider
1. 通过公共 URL 来访问 Bytebase，点击右上角的齿轮 > 集成 > GitOps，选择 gitlab.com，点击下一步。你会进入到第二步，拷贝 Redirect URI。
![file](https://img-blog.csdnimg.cn/44168f05ae204aa7a26252d347148d1a.png)
2. 访问 [GitLab](gitlab.com)，点击头像，选择下拉菜单中的偏好设置，在左侧栏中选择应用。填写表格如下并保存：- Name: Bytebase- Redirect URI: 从 Bytebase GitOps 配置里步骤 2 里复制- Confidential: Yes- Scope: api
![file](https://img-blog.csdnimg.cn/177c1e875bfb4404bb677e80ca5bcbca.png)
3. 从 GitLab 的应用页面复制 Application ID 和 Secret，然后粘贴到 Bytebase 的 GitOps 配置页面步骤 2 里。
![file](https://img-blog.csdnimg.cn/10f1d2d53d0d41c2b316bdce4dc69993.png)### 第三步 在 Bytebase 中配置一个 GitOps 工作流
1. 访问 [GitLab](gitlab.com)，并建立一个新项目 bytebase-gitlabcom-demo。将 Visibility Level（可见级别）设置为公共。点击建立项目。
2. 访问 Bytebase，进入项目 Sample Project。点击 GitOps 标签，选择 GitOps 工作流。点击 配置 GitOps。
3. 选择 GitLab.com（就是你在上一步配置的），然后选择 bytebase-gitlabcom-demo 这个项目。你会来到步骤三，保持其它参数不变，滑动到页面底部，勾选 基于 GitLab CI 开启 SQL 审核。点击完成。
Image
4. 系统会自动在 GitLab 中建立实现 CI 的 MR，跳转到 GitLab 中手动合并。
![file](https://img-blog.csdnimg.cn/6f3fe372a45a439d874079e9c4ae1797.png)
5. 回到 Bytebase，你会见到 GitOps 工作流已设置成功。### 第四步 建立一个 MR（合并请求）去触发 SQL 审核 CI
1. 点击界面顶端环境，你可以看到在 Prod 最下方有连接了一个 SQL 审核策略，点击编辑，你会看到有 3 条开启的规则。它们将通过 CI 应用。
![file](https://img-blog.csdnimg.cn/8496effb4cb644f0bec29baca556c0a3.png)
2. 为了测试 SQL 审核 CI，我们将创建一个合并请求来更改 Prod 数据库 schema。不过，我们会让它先违反下 SQL 审核策略。转到 GitLab 上的 bytebase-gitlabcom-demo。单击新建分支，命名为 add-nickname-table-employee，点击创建分支。
3. 在新分支上创建子目录 bytebase，并创建子子目录 prod。在 prod 目录中创建文件 `employee##202309262500##ddl##add_nickname_table_employee.sql`。将以下 SQL 脚本复制到文件中，并提交更改。

ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text;

4. 创建包含上述提交的合并请求。SQL 审核 CI 将自动运行并显示失败消息。不过，无论 CI 结果如何，你仍然可以合并它。
![file](https://img-blog.csdnimg.cn/799fcf5541834474b6ba7ad89c12ec17.png)
5. 更新 SQL 脚本并提交到当前分支。SQL 审核 CI 将再次运行并显示通过信息。单击合并。

ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text NOT NULL DEFAULT '';

![file](https://img-blog.csdnimg.cn/23cfb9b72a2749b28d5072efa30935b8.png)
6. 返回 Bytebase 中的 Sample Project，你会看到推送事件产生了一个工单。
![file](https://img-blog.csdnimg.cn/8f2b608f167f4992aaa1d01fcb94ba06.png)
7. 点击 issue/102 到问题详情页面。因为没有配置审批流或手动发布，此工单会自动发布。您可以点击查看变更来查看差异。
![file](https://img-blog.csdnimg.cn/4fd64b23390b4789a7097d54505fd773.png)## 通过 Bytebase 企业版解锁更多功能
您可以升级到企业版，解锁更多功能。点击左下角的开始免费试用并升级到企业版，点击顶部实例，为现有的两个实例分配证书。### 手动发布
在环境 > 2.Prod，找到发布策略，然后选择 人工发布 > 需要 DBA 或者 Bytebase 实例所有者发布。
![file](https://img-blog.csdnimg.cn/62196525f4834add9a0d2a82804335a5.png)### 自定义审批
1. 访问设置 > 安全性 & 策略 > 自定义审批。将项目 Project Owner -> DBA 设置为 DDL > 高风险的审批流。
![file](https://img-blog.csdnimg.cn/b16fd75559d04824a56600621954c60c.png)
2. 访问设置 > 安全性 & 策略 > 风险中心。点击添加规则，然后点击加载第一个模板，点击添加。
![file](https://img-blog.csdnimg.cn/9a13f5d476554e2eb54f94e055b0b1f4.png)### 最新 schema 写回
Schema 变更完成后，Bytebase 会将最新 schema 写回 Git 代码库。这样，团队在 Git 中就始终有一个数据库 schema 的标准真实源。
1. 返回 GitLab，新建一个分支 `add-country-table-employee`。在 bytebase/prod 目录下创建文件 `employee##202309261700##ddl##add_country_table_employee.sql`。将以下 SQL 脚本复制到文件中并提交更改。

ALTER TABLE "public"."employee" ADD COLUMN "country" text NOT NULL DEFAULT '';

2. 返回 Bytebase，转到新创建的工单，它符合 Project Owner  -> DBA 的审批流程。
![file](https://img-blog.csdnimg.cn/72d44f9def3440699874bf691a0a411e.png)
3. 按照审批流程点击批准后，横幅将显示等待发布。然后，负责人就可以点击 发布了。
4. 回到 GitLab，在 `bytebase/prod/` 下有一个新的文件 `.employee##LATEST.sql`，包含了 Bytebase 写回的最新 schema。### Schema 漂移
Bytebase 内置了 schema 漂移检测功能，可以检测到意外的 schema 变更。让我们使用 SQL 编辑器管理员模式来模拟一下。
1. 点击右上角的终端图标（SQL 编辑器）。你将跳转到 SQL 编辑器。点击管理员模式。在此模式下所做的一切与直接连接服务器相同，Bytebase 不会记录。
2. 选择左侧的 (Prod) Employee，粘贴并运行以下脚本：

ALTER TABLE "public"."employee" ADD COLUMN "city" text NOT NULL DEFAULT '';

```

3. 返回 Bytebase 主页，点击顶部的数据库， 选择 Prod 下的 employee。点击现在同步。看到成功消息后，刷新页面。你将看到 schema 漂移。你可以在实例详情页配置自动扫描，以避免手动同步。
4. 访问异常中心，也会看到 schema 漂移。

总结

有了 Bytebase，你就有了一套完整的 GitLab 数据库 CI/CD 工作流程。您可以将此工作流程应用到自己的项目中，并根据自己的需要进行定制。 Bytebase 也支持 GitHub，Bitbucket 以及 Azure DevOps。具体的配置步骤可以查看文档。

---

💡 你可以访问官网，免费注册云账号，立即体验 Bytebase。