济南网站建设飞鸟,广州怎么建设一个网站,北京百度推广优化,网站开通支付宝接口数据库变更一直是整个应用发布过程中效率最低、流程最复杂、风险最高的环节#xff0c;也是 DevOps 流程中最难以攻克的阵地。那我们是否能在具体的 CI/CD 流程中#xff0c;像处理代码那样处理数据库变更呢#xff1f; DORA 调研报告
DORA#xff08;DevOps Research 也是 DevOps 流程中最难以攻克的阵地。那我们是否能在具体的 CI/CD 流程中像处理代码那样处理数据库变更呢 DORA 调研报告
DORADevOps 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: 可以任取一个名字比如 bbHomepage URL: https://bytebase.comAuthorization 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 也支持 GitLabGitHub以及 Bitbucket。具体的配置步骤可以查看 Bytebase 官网文档。 更多资讯请关注 Bytebase 公号Bytebase
