DAG 版本管理与发布
DAG 代码本质是程序，应该和应用程序一样走版本管理：提交到 Git、走评审、由流水线发布到调度环境（例如 git-sync 或 CI 推送 dags 目录），而不是直接在生产目录手改文件。稳定性靠两条约定：dag_id 与 task_id 保持稳定（新增任务而不是改名），改动采用增量演进；回滚时能定位到具体 commit 与生效时刻。这样出问题可以按版本回退，历史重跑的语义也不会因改名而混乱。
基本信息
| 代码托管 | Git 仓库加合并请求评审 |
|---|---|
| 发布方式 | git-sync 定时同步或 CI 推送 dags 目录 |
| 兼容策略 | dag_id 稳定，新增任务而非改名 |
| 回滚方式 | 按 commit 或 tag 回退 DAG 文件 |
| 配套要求 | DAG 文件记录 owner 与变更原因 |
典型使用场景
- 多人协作开发 DAG：通过合并请求评审，避免互相覆盖
- 发布失败需要回滚：按 tag 恢复上一个可用版本
- 排查历史异常：确认某天运行的到底是哪个版本的代码
- 大改前的安全做法：先保留旧 DAG，新 DAG 用新 dag_id 并行验证
- 多环境发布：同一份代码按环境注入不同连接与变量
发布与回滚示意
发布与回滚示意
# 打标签，标记本次发布对应的代码版本
git tag dag-release-2026.10.12
# CI 中先校验 DagBag 可解析，再同步到调度环境
python -c "from airflow.models import DagBag; d=DagBag('dags'); assert not d.import_errors"
# 回滚：按上一个标签取回单个 DAG 文件
git checkout dag-release-2026.10.11 -- dags/daily_orders.py
# 记录：变更原因、影响范围、是否需要回刷历史分区发布方式对照
| 方式 | 机制 | 优点 | 风险 |
|---|---|---|---|
| git-sync | sidecar 定时拉取仓库 | 环境一致、回滚容易 | 同步延迟需评估 |
| CI 推送 | 流水线打包推送 dags 目录 | 可控、可加校验 | 推送中断可能产生半成品 |
| 手工上传 | 直接在界面或目录改 | 临时方便 | 无版本记录，难回滚 |
给 DAG 文件记录 owner 与变更原因：DAG 数量一多，仅靠记忆回溯变更成本很高，评审记录是最省事的依据。
直接在生产 dags 目录手改文件，出问题时没有可回退的版本，也说不清当时改了什么，属于典型的高风险操作。
大改 task_id 会让重跑语义混乱：历史实例记录指向的是旧任务名，报表与回溯对上号时会发现半截数据来自旧任务。