在 CI/CD 流程中，应用代码通常已具备提交、测试、构建和发布机制，但数据库变更常常游离于代码质量门禁与生产发布控制之外。从代码仓库中的 SQL 变更，到合并前审核、发布审批和生产受控执行之间，仍然缺少完整的数据库治理链路。
NineData GitOps SQL 代码审核将 SQL 检查接入现有 CI/CD 流水线。开发人员提交代码、创建 Merge Request 或触发发布任务时，流水线可执行
ninedata check，审核本次变更中的 SQL 文件和 MyBatis XML 文件，并将结果输出到代码平台。这样，数据库变更能够和应用代码一样，在合并前完成质量检查，并在后续发布阶段衔接数据库变更审批、受控执行和审计留痕。
GitOps 场景下，为什么还需要 SQL 审核？
业务代码通常会经过静态扫描、单元测试和 Code Review，但数据库变更经常以以下形式存在：
- Flyway、Liquibase 或自定义目录中的
.sql文件； - MyBatis Mapper XML 中的查询和更新语句；
- 发布脚本中的 DDL、DML；
- 应用迭代中新增或修改的数据库访问逻辑。
如果 SQL 没有在合并前完成检查，就可能将性能和安全风险带入生产环境。例如：
- 查询缺少合适索引，发布后拖慢核心业务；
-
UPDATE、DELETE缺少约束条件； - SQL 不符合命名、语法或访问规范；
- 多人修改数据库相关代码，却没有统一审核标准；
- DBA 只能在发布窗口临时人工检查，影响交付效率。
NineData 将 SQL 审核前置到提交、合并请求或流水线阶段，让问题在进入发布流程前被发现。
NineData 如何接入 GitLab、Codeup？
NineData 支持将 SQL 代码审核接入 GitLab、云效 Codeup 等代码平台。核心方式是在 CI Job 中运行
ninedata check。流程分工如下：
- GitLab、Codeup 等代码平台负责触发时机、分支信息、代码工作区与审核结果展示。
- CI Job 根据文件匹配规则定位本次需要审核的 SQL 文件和 MyBatis XML 文件。
-
ninedata check解析 SQL，并调用 NineData 审核能力。 - NineData 根据目标数据源绑定的 SQL 开发规范、语法解析、慢 SQL 规则和索引推荐能力生成审核结果。
- 审核结果显示在流水线日志、报告文件或 Merge Request 页面中，由提交人、合并人或 DBA 决定后续操作。
接入前需要准备什么？
使用 GitOps SQL 审核前，需要完成以下准备：
- 已开通 NineData 数据库 DevOps 企业版；
- 已将目标数据库添加为 NineData 数据源；
- 已为目标数据源配置 SQL 开发规范；
- 已创建可调用 NineData OpenAPI 的访问凭证；
- 已为调用方授予 GitOps SQL 审核所需权限；
- CI Runner 或流水线容器能够访问 NineData 服务地址；
- 已确定需要审核的 SQL 文件目录和 MyBatis XML 目录。
当前支持审核：
-
.sql文件； - MyBatis XML 文件，例如 Mapper XML。
对于 Java、Go、Python 等代码文件中的内嵌 SQL，当前版本暂不支持自动解析。MyBatis XML 中动态 SQL 标签、复杂嵌套表达式和具体 MyBatis 版本的解析范围，应以当前产品版本测试结果或官方支持说明为准。
GitLab 接入示例
在 GitLab 项目根目录中创建
ninedata-review.yml，并由
.gitlab-ci.yml 引用：include: - local: ninedata-review.yml
在
ninedata-review.yml 中新增 SQL 审核 Job：sql-review: stage: test image: name: ninedata/ninedata-cicd:amd pull_policy: always variables: CREATOR: $GITLAB_USER_LOGIN NINEDATA_URL: $NINEDATA_URL CUR_BRANCH: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME TARGET_BRANCH: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME ACCESS_KEY: $NINEDATA_ACCESS_KEY ACCESS_SECRET: $NINEDATA_ACCESS_SECRET DATASOURCE_ID: $NINEDATA_DATASOURCE_ID DATABASE_NAME: $NINEDATA_DATABASE EVENT_SOURCE: $CI_PIPELINE_SOURCE script: - | ninedata check \ --url="$NINEDATA_URL" \ --creator="$CREATOR" \ --cur-branch="$CUR_BRANCH" \ --trg-branch="$TARGET_BRANCH" \ --access-key="$ACCESS_KEY" \ --access-secret="$ACCESS_SECRET" \ --file-patterns="migration/*.sql" \ --file-patterns="src/main/resources/config/mybatis/**/*.xml" \ --datasource="$DATASOURCE_ID" \ --db="$DATABASE_NAME" \ --event="$EVENT_SOURCE" artifacts: reports: codequality: ninedata_review_result.json rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - changes: - "migration/*.sql" - "src/main/resources/config/mybatis/**/*.xml"
该配置仅在 Merge Request 或指定 SQL、MyBatis XML 文件变更时触发审核，并将结果作为 GitLab Code Quality 报告输出。
NINEDATA_URL、AccessKey、AccessSecret、数据源 ID 和数据库名称应配置为 GitLab CI/CD Variables，不应明文写入代码仓库。Codeup 接入方式
在云效 Codeup 中，可通过合并检查、发布流水线或自定义任务接入 NineData SQL 审核。
配置重点包括：
- 在流水线中新增 SQL 审核任务。
- 使用
container指定 NineData GitOps CI 镜像。 - 通过
pathFilter限定触发范围，例如src/main/resources/config/mybatis/**/*.xml。 - 在命令步骤执行
ninedata check。 - 将审核结果作为流水线日志、报告或 Codeup CI 节点结果展示。
示例：
sources: repo_0: type: codeup name:endpoint: branch: dev triggerEvents: - mergeRequestOpenedOrUpdate pathFilter: src/main/resources/config/mybatis/**/*.xml defaultWorkspace: repo_0 stages: stage_0: name: SQL 审核 jobs: job_0: name: Ninedata_CI runsOn: group: public/cn-hangzhou labels: linux,amd64 container: ninedata/ninedata-cicd:amd steps: step_0: name: 执行 SQL 审核 step: Command with: run: |- ninedata check \ --url="$NINEDATA_URL" \ --creator="$BUILD_EXECUTOR" \ --cur-branch="$CI_COMMIT_REF_NAME" \ --trg-branch="$CI_COMMIT_TARGET_REF_NAME" \ --access-key="$NINEDATA_ACCESS_KEY" \ --access-secret="$NINEDATA_ACCESS_SECRET" \ --file-patterns="src/main/resources/config/mybatis/**/*.xml" \ --file-patterns="migration/*.sql" \ --datasource="$NINEDATA_DATASOURCE_ID" \ --db="$NINEDATA_DATABASE" \ --event="merge-request-event"
Codeup 中的 NineData 服务地址、访问凭证、目标数据源 ID 和数据库名称，同样应使用流水线变量或企业密钥管理服务保存。
审核结果如何进入发布决策？
NineData 会输出命中的 SQL 规则、问题 SQL 和优化建议。团队可在 Job 日志、报告文件、Merge Request 页面或 CI 节点中查看结果。
当前 GitOps SQL 审核结果默认用于展示，NineData 不会在代码平台侧直接强制阻塞合并或发布。是否阻塞，由企业自身的 CI/CD 策略决定。
| 审核结果 | 推荐处理方式 |
| 审核通过 | 正常进入构建、测试和发布流程 |
| 规范提醒或低风险优化建议 | 在 Merge Request 中展示，由开发人员评估处理 |
| 高风险 SQL 或严重性能问题 | 在 CI 中配置失败条件，修复后重新提交 |
| 审核调用失败 | 暂停后续发布或转人工确认；依次检查 NineData 服务地址、网络连通性、凭证有效性与权限、目标数据源 ID、数据库名称及 SQL 开发规范配置 |
建议先在测试或 Merge Request 流水线中以报告模式运行，再根据规则命中情况设置 CI 阻塞策略。
从 SQL 检查到数据库变更治理
GitOps SQL 审核解决的是“SQL 在合并前是否符合规范”。对于真正进入生产环境的数据变更，还应结合 NineData 的数据库变更审批、权限控制、执行审计和回滚能力。
一个完整流程可以是：
- 开发人员在代码仓库提交 SQL 或 MyBatis XML 变更。
- GitLab、Codeup 触发
ninedata check。 - SQL 规则、慢 SQL 风险和索引建议在 Merge Request 或流水线中展示。
- 代码和 SQL 审核通过后，进入构建、测试和应用发布。
- 生产数据变更通过 NineData 的审批和受控执行流程完成。
- 代码平台保留审核报告，NineData 保留数据库操作与变更记录。
这样，数据库变更不再是应用发布流程之外的人工操作，而是从代码提交到生产执行都可治理的一部分。
总结
NineData GitOps SQL 审核通过
ninedata check，将 SQL 文件和 MyBatis XML 中的数据库变更接入 GitLab、Codeup 等 CI/CD 流水线。开发人员可在合并前获得 SQL 规则、性能风险和优化建议；DBA 可将审核规范沉淀为团队标准；企业可在不改变现有 GitOps 流程的前提下，将数据库变更纳入统一质量治理。