数据库变更一直是整个应用发布过程中效率最低、流程最复杂、风险最高的环节,也是 DevOps 流程中最难以攻克的阵地。那我们是否能在具体的 CI/CD 流程中,像处理代码那样处理数据库变更呢?
DORA 调研报告
DORA(DevOps Research & Assessment)是一家专注于 DevOps 的研究机构, 在该领域以专业与客观著称。自 2014 年以来,DevOps 调研了全球范围内超过 32,000 名专业人员,并以年度报告的形式对外发布研究成果。DORA 明确指出,将数据库变更纳入应用发布流程将显著提升整体发布效率。
这一结论并不令人意外。问题是,该怎么做?
一个完整的基于 Azure DevOps 的数据库 CI/CD 工作流
通过 Bytebase,我们将实现一个完整的基于 Azure DevOps 的数据库 CI/CD 工作流:
- 开发者将变更 SQL 脚本提交到代码分支;
- 触发 Bytebase 提供的 SQL 审核 CI 进行自动化 SQL 审核,并给出修改建议;
- 修改完成后的 SQL 脚本合并入主分支;
- 自动触发发布流程,脚本将被推送到 Bytebase 中;
- Bytebase 内置的自动审核将对变更语句进行二次确认,根据变更风险等级自动匹配审批流,根据审批流进行审批;
- 审批后的语句可手动或自动触发在目标库中执行;
- 变更完成后的数据库最新 schema 结构将被自动回写入代码仓库;
- 确认变更完成后,触发下一阶段的应用发布流程。
通过 Bytebase 社区版实现
让我们一步一步看看这个过程怎样实现的。
第一步 通过 Docker 启动 Bytebase,并配置外部 URL
ngrok 是一个反向代理工具,我们需要它的公网地址,以便从 GitHub 接收 webhooks。这里使用 ngrok 是出于测试目的;对于生产使用,我们建议使用 Caddy。
-
登录 ngrok Dashboard,并按照 Getting Started 步骤进行安装和配置。
-
在 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.10.0
--data /var/opt/bytebase
--port 8080 -
Bytebase 在 Docker 中成功启动,你可以通过
localhost:5678
来访问。注册一个管理员账号。 -
在命令行运行
ngrok http 5678
,并获得公共 URL。
- 登录 Bytebase,点击右上角的齿轮,将公共 URL 填入到网络部分的外部 URL,点击更新。
第二步 在 Bytebase 种添加 Azure DevOps Service 作为 Git Provider
- 通过公共 URL 来访问 Bytebase,点击右上角的齿轮 > 集成 > GitOps,选择 Azure DevOps Service,点击下一步。你会进入到第二步,拷贝 Redirect URI。点击 直达链接 访问你的 Azure DevOps 账号。
- 在 Azure DevOps 的应用注册页面,填写表格如下并保存:
- Company name: 可以任取一个名字,比如
bb
- Homepage URL:
https://bytebase.com
- Authorization callback URL: 从 Bytebase 步骤 2 复制的 Redirect URI
- Authorizied scopes: 找到 Code (full), Identity (read), Project and team (read), Build (read and execute)
- 点击 show,复制 Application ID 和 Client Secret,然后粘贴到 Bytebase 的 GitOps 配置页面步骤 2 里。
第三步 在 Bytebase 中配置一个 GitOps 工作流
- 访问 Azure DevOps,并建立一个新项目 bytebase-gitops。
- 访问 Bytebase,进入项目 Sample Project。点击 GitOps 标签,选择 GitOps 工作流。点击 配置 GitOps。
- 选择 Azure DevOps(就是你在上一步配置的),然后选择 bytebase-gitops 这个项目。你会来到步骤三,保持其它参数不变,滑动到页面底部,勾选 基于 Azure DevOps Pipeline 开启 SQL 审核。点击完成。
- 系统会自动在 Azure DevOps 中建立实现 CI 的 PR,点击 Complete 手动合并。回到目录,可以看到 pipeline 自动生成。
- 回到 Bytebase,你会见到 GitOps 工作流已设置成功。
第四步 建立一个 PR(合并请求)去触发 SQL 审核 CI
- 点击界面顶端环境,你可以看到在 Prod 最下方有了一个 SQL 审核策略,点击编辑,你会看到有 3 条开启的规则。它们将通过 CI 应用。我们将非空的等级调为错误。
- 为了测试 SQL 审核 CI,我们将创建一个合并请求来更改 Prod 数据库 schema。不过,我们会让它先违反下 SQL 审核策略。Azure DevOps 上的 bytebase-gitops-az。单击新建分支,命名为 add-nickname-table-employee,点击创建分支。
- 在新分支上创建子目录 bytebase,并创建子子目录 prod。在 prod 目录中创建文件 employee##202310201700##ddl##add_nickname_table_employee.sql。将以下 SQL 脚本复制到文件中,并提交更改。
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text;
- 创建包含上述提交的合并请求。SQL 审核 CI 将自动运行并显示失败消息。点击 Tests 可以看到具体的违反规则。
- 更新 SQL 脚本并提交到当前分支。SQL 审核 CI 将再次运行并显示通过信息。单击 Complete。
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text NOT NULL DEFAULT '';
- 返回 Bytebase 中的 Sample Project,你会看到推送事件开启了一个工单。
- 到问题详情页面。因为没有配置审批流或手动发布,此工单会自动发布。你可以点击查看变更来查看差异。
通过 Bytebase 企业版解锁更多功能
你可以升级到企业版,解锁更多功能。点击页面左下角的开始免费试用并升级到企业版,点击顶部实例,为现有的两个实例分配证书。
手动发布
在环境 > 2.Prod,找到发布策略,然后选择 人工发布 > 需要 DBA 或者 Bytebase 实例所有者发布。
自定义审批
- 访问设置 > 安全性 & 策略 > 自定义审批。将项目 Project Owner -> DBA 设置为DDL > 高风险的审批流。
- 访问设置 > 安全性 & 策略 > 风险中心。点击添加规则,然后点击加载第一个模板,点击添加。
最新 schema 写回
Schema 变更完成后,Bytebase 会将最新 schema 写回 Git 代码库。这样,团队在 Git 中就始终有一个数据库 schema 的标准真实源。
- 返回 Azure DevOps,新建一个分支 add-country-table-employee。在 bytebase/prod 目录下创建文件
employee##202310201700##ddl##add_country_table_employee.sql
。将以下 SQL 脚本复制到文件中并提交更改。ALTER TABLE "public"."employee" ADD COLUMN "country" text NOT NULL DEFAULT '';
- 返回 Bytebase,转到新创建的工单,它符合 Project Owner -> DBA 的审批流程。
- 按照审批流程点击批准后,横幅将显示等待发布。然后,负责人就可以点击发布了。
- 回到 GitLab,你会发现在
bytebase/prod/
下有一个新的文件.employee##LATEST.sql
,包含了 Bytebase 写回的最新 schema。(这里需要开启推送到 main 的权限)
Schema 漂移
Bytebase 内置了 schema 漂移检测功能,可以检测到意外的 schema 变更。让我们使用 SQL 编辑器管理员模式来模拟一下。
-
点击右上角的终端图标(SQL 编辑器)。你将跳转到 SQL 编辑器。点击管理员模式。在此模式下所做的一切与直接连接服务器相同,Bytebase 不会记录。
-
选择左侧的 (Prod) Employee,粘贴并运行以下脚本:
ALTER TABLE "public"."employee" ADD COLUMN "city" text NOT NULL DEFAULT '';
- 返回 Bytebase 主页,点击顶部的数据库, 选择 Prod 下的 employee。点击现在同步。看到成功消息后,刷新页面。你将看到 schema 漂移。你可以在实例详情页配置自动扫描,以避免手动同步。
- 访问异常中心,也会看到 schema 漂移。
总结
有了 Bytebase,你就有了一套完整的 Azure DevOps 数据库 CI/CD 工作流程。你可以将此工作流程应用到自己的项目中,并根据自己的需要进行定制。 Bytebase 也支持 GitLab,GitHub,以及 Bitbucket。具体的配置步骤可以查看 Bytebase 官网文档。
💡 更多资讯,请关注 Bytebase 公号:Bytebase