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

原创
2023/10/11 12:09
阅读数 657

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

file

DORA 调研报告

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

file

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

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

file

通过 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

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.8.0 \
--data /var/opt/bytebase \
--port 8080
  1. Bytebase 通过 Docker 成功启动,你可以通过 localhost:5678 来访问。注册一个管理员账号。
  2. 在命令行运行 ngrok http 5678 ,并获得公共 URL。 file
  3. 登录 Bytebase,点击右上角的齿轮,将公共 URL 填入到网络部分的外部 URL,点击更新。

第二步 在 Bytebase 种添加 GitLab.com 作为 Git Provider

  1. 通过公共 URL 来访问 Bytebase,点击右上角的齿轮 > 集成 > GitOps,选择 gitlab.com,点击下一步。你会进入到第二步,拷贝 Redirect URI。 file
  2. 访问 GitLab,点击头像,选择下拉菜单中的偏好设置,在左侧栏中选择应用。填写表格如下并保存:
    • Name: Bytebase
    • Redirect URI: 从 Bytebase GitOps 配置里步骤 2 里复制
    • Confidential: Yes
    • Scope: api file
  3. 从 GitLab 的应用页面复制 Application ID 和 Secret,然后粘贴到 Bytebase 的 GitOps 配置页面步骤 2 里。 file

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

  1. 访问 GitLab,并建立一个新项目 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
  5. 回到 Bytebase,你会见到 GitOps 工作流已设置成功。

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

  1. 点击界面顶端环境,你可以看到在 Prod 最下方有连接了一个 SQL 审核策略,点击编辑,你会看到有 3 条开启的规则。它们将通过 CI 应用。 file
  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;
  1. 创建包含上述提交的合并请求。SQL 审核 CI 将自动运行并显示失败消息。不过,无论 CI 结果如何,你仍然可以合并它。 file
  2. 更新 SQL 脚本并提交到当前分支。SQL 审核 CI 将再次运行并显示通过信息。单击合并。
ALTER TABLE "public"."employee" ADD COLUMN "nick_name" text NOT NULL DEFAULT '';

file 6. 返回 Bytebase 中的 Sample Project,你会看到推送事件产生了一个工单。 file 7. 点击 issue/102 到问题详情页面。因为没有配置审批流或手动发布,此工单会自动发布。您可以点击查看变更来查看差异。 file

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

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

手动发布

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

自定义审批

  1. 访问设置 > 安全性 & 策略 > 自定义审批。将项目 Project Owner -> DBA 设置为 DDL > 高风险的审批流。 file
  2. 访问设置 > 安全性 & 策略 > 风险中心。点击添加规则,然后点击加载第一个模板,点击添加。 file

最新 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 '';
  1. 返回 Bytebase,转到新创建的工单,它符合 Project Owner -> DBA 的审批流程。 file
  2. 按照审批流程点击批准后,横幅将显示等待发布。然后,负责人就可以点击 发布了。
  3. 回到 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 '';
  1. 返回 Bytebase 主页,点击顶部的数据库, 选择 Prod 下的 employee。点击现在同步。看到成功消息后,刷新页面。你将看到 schema 漂移。你可以在实例详情页配置自动扫描,以避免手动同步。 file
  2. 访问异常中心,也会看到 schema 漂移。

总结

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


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

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