3. 数据管道版本控制策略

在 DataOps 的持续交付链路中，版本控制不只是“把代码放进 Git”这么简单。数据管道由多种异构资产组成：Python/Scala 作业代码、编排定义（如 Airflow DAG、Step Functions 状态机）、SQL 转换脚本、Schema 契约、连接与运行参数、以及 IaC 模板。这些资产的变化频率、影响范围和回滚代价各不相同，因此需要一套分层的版本控制策略，让每一次变更都可追溯、可评审、可回滚。

一、四类资产的版本管理边界

先明确“什么进仓库、以什么粒度进仓库”。实践中建议按以下边界划分：

• 管道代码：ETL/ELT 作业逻辑、UDF、单元测试。与业务逻辑强相关，必须完整纳入版本控制，按功能分支开发。
• 配置：环境参数、并发度、重试策略、资源规格。建议“代码与配置分离”，配置按环境（dev/staging/prod）分目录或分文件管理，敏感值通过 Secrets Manager 引用而非明文提交。
• SQL 脚本：建模、清洗、聚合逻辑。SQL 是数据管道中最易被忽视却最常变更的资产，应作为一等公民纳入仓库，并配套格式化与静态检查。
• Schema 定义：表结构、字段类型、分区键、契约文件（如 Avro/JSON Schema）。Schema 变更往往引发下游断裂，必须显式版本化并触发兼容性校验。

一个可参考的仓库结构如下，它把“代码、配置、SQL、Schema”四类资产在目录层面显式分开，便于按类型设置不同的评审规则：

data-pipeline-repo/
├── jobs/                 # 管道代码（Python/Scala）
│   ├── ingest_orders.py
│   └── transform_orders.py
├── dags/                 # 编排定义
│   └── orders_daily_dag.py
├── sql/                  # SQL 脚本
│   ├── staging/stg_orders.sql
│   └── mart/fct_orders_daily.sql
├── schemas/              # Schema 契约
│   └── orders_v2.avsc
├── config/
│   ├── dev.yaml
│   ├── staging.yaml
│   └── prod.yaml
└── tests/
    └── test_transform_orders.py

二、分支策略：主干保护 + 短生命周期功能分支

数据管道推荐采用“主干保护 + 短生命周期功能分支”的轻量策略，而非复杂的 Git Flow。原因在于数据管道变更频繁、需要快速验证，长期存在的 develop/release 分支容易造成 Schema 与配置漂移。

具体做法：main 分支始终对应可部署到生产的状态，并开启分支保护——禁止直接推送、要求至少 1 名评审人批准、要求 CI 检查通过。开发者在 feature/xxx 分支上工作，完成后通过 Pull Request 合并。对于紧急修复，使用 hotfix/xxx 分支，但仍需走 PR 流程，只是可缩短评审时限。

分支命名建议携带变更类型，便于自动化识别影响范围，例如 feature/add-order-dedup、schema/orders-add-currency、config/prod-concurrency。CI 可据此决定触发哪些检查：Schema 分支强制跑兼容性校验，配置分支强制跑参数合法性校验。

三、用 CodeCommit 落地评审与自动化门禁

AWS CodeCommit 提供托管 Git 仓库，并与 CodePipeline、CodeBuild、IAM 深度集成，适合作为数据管道的版本控制中枢。落地时重点配置三件事：

1. 分支保护与审批规则：在 CodeCommit 中为 main 创建 approval rule template，要求至少 1 个批准，且禁止批准人自审。可将模板关联到所有数据管道仓库，统一治理。
2. PR 触发校验：通过 EventBridge 捕获 CodeCommit 的 Pull Request 事件，触发 CodeBuild 执行 SQL lint、Schema 兼容性检查、单元测试。检查未通过则 PR 无法合并。
3. 合并后触发流水线：main 分支的 push 事件触发 CodePipeline，进入构建、测试、部署阶段，实现“合并即交付”。

下面这段示例展示了一个 PR 校验构建规范的核心步骤，用于在合并前拦截 Schema 不兼容与 SQL 语法问题：

version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.11
    commands:
      - pip install sqlfluff avro-python3
  build:
    commands:
      - echo "校验 SQL 规范"
      - sqlfluff lint sql/ --dialect ansi
      - echo "校验 Schema 向后兼容"
      - python scripts/check_schema_compat.py schemas/orders_v2.avsc
      - echo "运行单元测试"
      - pytest tests/ -q

其中 check_schema_compat.py 的职责是：读取新 Schema 与仓库中上一版本 Schema，逐字段比对，若出现“删除字段、修改字段类型、重命名字段”等破坏性变更，则返回非零退出码，阻断合并。这类门禁把 Schema 治理从“事后救火”前移到“合并前拦截”。

四、版本控制策略全景

把上述四类资产、分支模型与 CodeCommit 门禁串起来，可以得到一张完整的策略关系图。图中左侧是四类资产及其版本化要点，中间是分支与 PR 流程，右侧是 CodeCommit 提供的评审与自动化能力，底部是合并后进入持续交付的出口。

五、Schema 变更的版本化实操要点

Schema 是数据管道中最容易引发连锁故障的资产，值得单独说明其版本化方法。推荐采用“契约文件 + 兼容性检查 + 版本号”三件套：

• 每个数据集维护一个契约文件，文件名带主版本号，如 orders_v2.avsc，字段中标注 default 值以支持新增字段的向后兼容。
• 在 CI 中执行兼容性检查，规则可设为：允许新增带默认值的可选字段；禁止删除字段、禁止修改字段类型、禁止重命名。破坏性变更必须升主版本号并同步通知下游。
• Schema 变更的 PR 描述中必须写明“影响的下游表/作业”和“迁移窗口”，评审人据此判断是否需要协调发布。

六、配置与代码分离的落地方式

配置版本化的关键是“同一份代码 + 不同环境配置”。推荐用 YAML 文件按环境存放，代码通过环境变量或参数读取当前环境对应的配置文件。例如 config/prod.yaml 中定义并发度、重试次数、目标表名等：

# config/prod.yaml
pipeline:
  name: orders_daily
  concurrency: 8
  retry: 3
  target_table: mart.fct_orders_daily
  source_bucket: s3://prod-orders-raw/
  secret_ref: arn:aws:secretsmanager:...:orders-db

敏感信息（数据库口令、API Key）不写入 YAML，只写 Secrets Manager 的 ARN，由运行时解析。这样配置可以安全地进入 CodeCommit，评审时也能清楚看到参数变化。配置变更同样走 PR，并在 CI 中校验字段完整性与取值范围，避免把 concurrency 误设为 0 这类问题带到生产。

七、版本控制策略检查清单

在把上述策略落地到团队时，可用下面这份清单逐项核对，确保四类资产都被覆盖、门禁都生效：

版本控制策略的价值不在于工具本身，而在于让“谁在什么时候改了什么、为什么改、影响哪些下游”成为可回答的问题。当四类资产都被显式版本化、分支与评审规则被自动化执行、Schema 与配置变更被门禁拦截时，数据管道的持续交付才具备稳定的基础。