查看原文
其他

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

Adela Bytebase 2023-12-22


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


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

一个完整的基于 Azure DevOps 的数据库 CI/CD 工作流
通过 Bytebase,我们将实现一个完整的基于 Azure DevOps 的数据库 CI/CD 工作流
  1. 开发者将变更 SQL 脚本提交到代码分支;

  2. 触发 Bytebase 提供的 SQL 审核 CI 进行自动化 SQL 审核,并给出修改建议;

  3. 修改完成后的 SQL 脚本合并入主分支;

  4. 自动触发发布流程,脚本将被推送到 Bytebase 中;

  5. Bytebase 内置的自动审核将对变更语句进行二次确认,根据变更风险等级自动匹配审批流,根据审批流进行审批;

  6. 审批后的语句可手动或自动触发在目标库中执行;

  7. 变更完成后的数据库最新 schema 结构将被自动回写入代码仓库;

  8. 确认变更完成后,触发下一阶段的应用发布流程。


通过 Bytebase 社区版实现
让我们一步一步看看这个过程怎样实现的。
第一步 通过 Docker 启动 Bytebase,并配置外部 URL
ngrok (https://ngrok.com/) 是一个反向代理工具,我们需要它的公网地址,以便从 GitHub 接收 webhooks。这里使用 ngrok 是出于测试目的;对于生产使用,我们建议使用 Caddy (https://caddyserver.com/)。
1. 登录 ngrok Dashboard(https://dashboard.ngrok.com/get-started/setup),并按照 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
3. Bytebase 在 Docker 中成功启动,你可以通过 localhost:5678 来访问。注册一个管理员账号。
4. 在命令行运行 ngrok http 5678,并获得公共 URL https://b67d-154-212-161-108.ngrok-free.app。
5. 登录 Bytebase,点击右上角的齿轮,将公共 URL 填入到网络部分的外部 URL,点击更新
第二步 在 Bytebase 种添加 Azure DevOps Service 作为 Git Provider
1. 通过公共 URL 来访问 Bytebase,点击右上角的齿轮 > 集成 > GitOps,选择 Azure DevOps Service,点击下一步。你会进入到第二步,拷贝 Redirect URI。点击 直达链接 访问你的 Azure DevOps 账号。
2. 在 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
3. 点击 show,复制 Application IDClient Secret,然后粘贴到 Bytebase 的 GitOps 配置页面步骤 2 里。

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

1. 访问 Azure DevOps,并建立一个新项目 bytebase-gitops。
2. 访问 Bytebase,进入项目 Sample Project。点击 GitOps 标签,选择 GitOps 工作流。点击 配置 GitOps。
3. 选择 Azure DevOps(就是你在上一步配置的),然后选择 bytebase-gitops 这个项目。你会来到步骤三,保持其它参数不变,滑动到页面底部,勾选 基于 Azure DevOps Pipeline 开启 SQL 审核。点击完成
4. 系统会自动在 Azure DevOps 中建立实现 CI 的 PR,点击 Complete 手动合并。回到目录,可以看到 pipeline 自动生成。
5. 回到 Bytebase,你会见到 GitOps 工作流已设置成功。
第四步 建立一个 PR(合并请求)去触发 SQL 审核 CI
1. 点击界面顶端环境,你可以看到在 Prod 最下方有了一个 SQL 审核策略,点击编辑,你会看到有 3 条开启的规则。它们将通过 CI 应用。我们将非空的等级调为错误。
2. 为了测试 SQL 审核 CI,我们将创建一个合并请求来更改 Prod 数据库 schema。不过,我们会让它先违反下 SQL 审核策略。Azure DevOps 上的 bytebase-gitops-az。单击新建分支,命名为 add-nickname-table-employee,点击创建分支
3. 在新分支上创建子目录 bytebase,并创建子子目录 prod。在 prod 目录中创建文件 employee##202310201700##ddl##add_nickname_table_employee.sql。将以下 SQL 脚本复制到文件中,并提交更改。
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text;

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

5. 更新 SQL 脚本并提交到当前分支。SQL 审核 CI 将再次运行并显示通过信息。单击 Complete
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text NOT NULL DEFAULT '';
6. 返回 Bytebase 中的 Sample Project,你会看到推送事件开启了一个工单。
7. 到问题详情页面。因为没有配置审批流或手动发布,此工单会自动发布。你可以点击查看变更来查看差异。
通过 Bytebase 企业版解锁更多功能
你可以升级到企业版,解锁更多功能。点击页面左下角的开始免费试用并升级到企业版,点击顶部实例,为现有的两个实例分配证书。
手动发布

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

自定义审批

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

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

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

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

Star History 九月开源精选 |开源 GitHub Copilot 替代
Bytebase 2.10.0 - 支持更灵活的变更发布人:指定任意角色或自定义审批流的最后节点
Spirit:继承 gh-ost 灵魂的 MySQL 在线大表变更方案
一家全球化创业公司背后的40+ SaaS服务和成本:2023版


继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存