Bytebase SQL审核|将结果与代码提交进行关联
整体的体验还是很赞的，GitOps方式的SQL审核体验很不错。将SQL审核结果与提交或者合并请求关联：可以开启GitOps通过GitLabCI/CD或者GitHub action进行SQL审核。我的体验过程分享给大家！
注册Bytebase Cloud
访问https://www.bytebase.com/，然后单击右上角的“注册云服务” 。
可以通过电子邮件/Google/GitHub/Microsoft 帐户注册或登录 Bytebase Hub。此处使用Github登入。
登入后，将被重定向到工作区页面，单击创建工作区。请注意，每个帐户只允许一个工作区。
等待几分钟以配置工作区，然后检查您的电子邮件以获取登录链接、电子邮件和密码。
配置数据库GitOps
导航到“设置” 单击左侧菜单GitOps进入配置。此处选择GitLab进行演示。填写GitLab服务地址，单击下一步
进入GitLab平台创建一个OAuth认证APP， 如图所示。
创建应用后，复制应用ID和Secret填写到项目集成中。
集成完成，单击确认并添加完成GitOps配置。
创建测试项目， 开启GitOps工作流。如图所示。
选择集成的GitLab Project， 如图所示。
测试GitOps
选择Cloud中以存在的测试数据库。如图所示。选择环境、填写数据库名称。单击创建。
配置SQL审核策略：选择环境开启审核策略。
在远程仓库中新建SQL变更文件。（注意文件名称以.sql为后缀）
代码提交会Bytebase自动生成工单。单击工单可以看到当Schema 或者数据变更时会自动进行SQL审核。如图所示。
单击SQL审核可以看到检查结果。
如果语法错误或者审核错误，如图所示。
进行Query查询也会对查询的SQL进行审核。如果未出现SQL检查结果可能是因为当前环境未开启SQL审核策略。
GitOps SQL审核
基于GitLab CI 开启SQL审核
Bytebase 会初始化发起合并请求为您的代码仓库配置 SQL 审核 CI。
初始化的过程会添加gitlab-ci.yaml配置文件。也就是当后续创建合并请求时会调用api对仓库中的SQL文件进行审核。
bytebase-sql-review:
only:
refs:
- merge_requests
image: docker:stable
variables:
API: "https://ovxlixlc.us-central1.bytebase.com/hook/sql-review/workspace_zytest-ujognaj-1682219285" # This is the API for SQL reivew.
before_script:
- apk update && apk add curl
- apk update && apk add jq
script:
- echo "Start request $API"
- request_body=$(jq -n --arg repositoryId "$CI_PROJECT_ID" --arg pullRequestId $CI_MERGE_REQUEST_IID --arg webURL "$CI_SERVER_URL" '$ARGS.named')
- 'response=$(curl -s --show-error -X POST "$API" -H "Content-type: application/json" -H "X-SQL-Review-Token: $SQL_REVIEW_API_SECRET" -d "$request_body")'
- echo $response
- content=$(echo $response | jq -r '.content')
- len=$(echo $content | jq '. | length')
- if [ $len == 0 ]; then exit 0; fi
- msg=$(echo $content | jq -r '.[0]')
- echo $msg >> bytebase-sql-review.xml
- status=$(echo $response | jq -r '.status')
- if [ "$status" == "ERROR" ]; then exit 1; fi
artifacts:
when: always
reports:
junit:
- bytebase-sql-review.xml
创建测试分支，并修改sql文件提交后。开启MR，可以看到SQL代码的测试结果。如图所示。
Q1: 配置 SQL 审核是否顺手？
web页面配置过程比较顺手。GitLabCI集成需要考虑到当前项目已经存在CI文件的场景，避免合并冲突。
Q2: 是否满足你的使用场景？
目前看到的是以环境级别配置的SQL审核， 我理解当PROD开启SQL审核后所有的项目都会启用这套规则。企业中场景更为复杂，可能有自定义和自选审核规则的场景。
Q3: 你觉得 SQL 审核还缺少点啥？
总结：整体的体验还是很赞的，GitOps方式的SQL审核体验很不错。
往期推荐