实现基于 Azure DevOps 的数据库 CI/CD 最佳实践

原创
2023/10/31 12:01
阅读数 36

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

file

DORA 调研报告

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

file

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

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

file

通过 Bytebase,我们将实现一个完整的基于 Azure DevOps 的数据库 CI/CD 工作流:

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

通过 Bytebase 社区版实现

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

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

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

file

  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.10.0 \
  --data /var/opt/bytebase \
  --port 8080
  1. Bytebase 在 Docker 中成功启动,你可以通过 localhost:5678 来访问。注册一个管理员账号。
  2. 在命令行运行 ngrok http 5678,并获得公共 URL。

file

  1. 登录 Bytebase,点击右上角的齿轮,将公共 URL 填入到网络部分的外部 URL,点击更新。

第二步 在 Bytebase 种添加 Azure DevOps Service 作为 Git Provider

  1. 通过公共 URL 来访问 Bytebase,点击右上角的齿轮 > 集成 > GitOps,选择 Azure DevOps Service,点击下一步。你会进入到第二步,拷贝 Redirect URI。点击 直达链接 访问你的 Azure DevOps 账号。

file file

  1. 在 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)

file

  1. 点击 show,复制 Application ID 和 Client Secret,然后粘贴到 Bytebase 的 GitOps 配置页面步骤 2 里。

file file

第三步 在 Bytebase 中配置一个 GitOps 工作流

  1. 访问 Azure DevOps,并建立一个新项目 bytebase-gitops。
  2. 访问 Bytebase,进入项目 Sample Project。点击 GitOps 标签,选择 GitOps 工作流。点击 配置 GitOps。
  3. 选择 Azure DevOps(就是你在上一步配置的),然后选择 bytebase-gitops 这个项目。你会来到步骤三,保持其它参数不变,滑动到页面底部,勾选 基于 Azure DevOps Pipeline 开启 SQL 审核。点击完成。

file

  1. 系统会自动在 Azure DevOps 中建立实现 CI 的 PR,点击 Complete 手动合并。回到目录,可以看到 pipeline 自动生成。

file

  1. 回到 Bytebase,你会见到 GitOps 工作流已设置成功。

第四步 建立一个 PR(合并请求)去触发 SQL 审核 CI

  1. 点击界面顶端环境,你可以看到在 Prod 最下方有了一个 SQL 审核策略,点击编辑,你会看到有 3 条开启的规则。它们将通过 CI 应用。我们将非空的等级调为错误。

file

  1. 为了测试 SQL 审核 CI,我们将创建一个合并请求来更改 Prod 数据库 schema。不过,我们会让它先违反下 SQL 审核策略。Azure DevOps 上的 bytebase-gitops-az。单击新建分支,命名为 add-nickname-table-employee,点击创建分支。
  2. 在新分支上创建子目录 bytebase,并创建子子目录 prod。在 prod 目录中创建文件 employee##202310201700##ddl##add_nickname_table_employee.sql。将以下 SQL 脚本复制到文件中,并提交更改。

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

  1. 创建包含上述提交的合并请求。SQL 审核 CI 将自动运行并显示失败消息。点击 Tests 可以看到具体的违反规则。

file file

  1. 更新 SQL 脚本并提交到当前分支。SQL 审核 CI 将再次运行并显示通过信息。单击 Complete。

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

file

  1. 返回 Bytebase 中的 Sample Project,你会看到推送事件开启了一个工单。

file

  1. 到问题详情页面。因为没有配置审批流或手动发布,此工单会自动发布。你可以点击查看变更来查看差异。

file

通过 Bytebase 企业版解锁更多功能

你可以升级到企业版,解锁更多功能。点击页面左下角的开始免费试用并升级到企业版,点击顶部实例,为现有的两个实例分配证书。

手动发布

在环境 > 2.Prod,找到发布策略,然后选择 人工发布 > 需要 DBA 或者 Bytebase 实例所有者发布。

file

自定义审批

  1. 访问设置 > 安全性 & 策略 > 自定义审批。将项目 Project Owner -> DBA 设置为DDL > 高风险的审批流。

file

  1. 访问设置 > 安全性 & 策略 > 风险中心。点击添加规则,然后点击加载第一个模板,点击添加。

file

最新 schema 写回

Schema 变更完成后,Bytebase 会将最新 schema 写回 Git 代码库。这样,团队在 Git 中就始终有一个数据库 schema 的标准真实源。

  1. 返回 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 '';
  2. 返回 Bytebase,转到新创建的工单,它符合 Project Owner -> DBA 的审批流程。

file

  1. 按照审批流程点击批准后,横幅将显示等待发布。然后,负责人就可以点击发布了。
  2. 回到 GitLab,你会发现在 bytebase/prod/ 下有一个新的文件 .employee##LATEST.sql,包含了 Bytebase 写回的最新 schema。(这里需要开启推送到 main 的权限)

file

Schema 漂移

Bytebase 内置了 schema 漂移检测功能,可以检测到意外的 schema 变更。让我们使用 SQL 编辑器管理员模式来模拟一下。

  1. 点击右上角的终端图标(SQL 编辑器)。你将跳转到 SQL 编辑器。点击管理员模式。在此模式下所做的一切与直接连接服务器相同,Bytebase 不会记录。

  2. 选择左侧的 (Prod) Employee,粘贴并运行以下脚本:

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

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

file

  1. 访问异常中心,也会看到 schema 漂移。

总结

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


💡 更多资讯,请关注 Bytebase 公号:Bytebase

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部