从 GitOps 到数据库变更：NineData 如何打通 CI/CD 的数据库治理链路

在 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 服务地址>"
    CUR_BRANCH: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
    TARGET_BRANCH: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
    ACCESS_KEY: "<NineData OpenAPI AccessKey>"
    ACCESS_SECRET: "<NineData OpenAPI AccessSecret>"
    DATASOURCE_ID: "<目标数据源 ID>"
    DATABASE_NAME: "<目标数据库名>"
    EVENT_SOURCE: $CI_PIPELINE_SOURCE
  script:
    - pwd
    - |
      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="src/main/resources/config/mybatis/console/mapper/*.xml" \
        --file-patterns="migration/*.sql" \
        --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/console/mapper/*.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: <Codeup 仓库名称>
    endpoint: <Codeup 仓库地址>
    branch: dev
    triggerEvents:
      - mergeRequestOpenedOrUpdate
    branchFilter: .*
    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 GitOps CI 镜像地址>
        steps:
          step_0:
            name: 执行命令
            step: Command
            with:
              ifGivenShell: false
              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" \
                  --db="$NINEDATA_DATABASE" \
                  --event="merge-request-event" \
                  --datasource="$NINEDATA_DATASOURCE_ID"
          step_1:
            name: 审核报告
            step: UnitTestReport
            with:
              reportPath: ./report/ninedata_review_result.html
              reporter: Java-JUnit
              failOnError: false

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 流程的前提下，将数据库变更纳入统一质量治理。