我们团队把 Databricks CI/CD 从「推就走」改成了十道

去年上半年组里还在用最朴素的 databricks bundle deploy -t prod，合并 main 分支就直接上生产。结果有次一个拼写错误的列名把核心仪表盘全跑挂了，回滚花了四十分钟。那次事后复盘定下来：生产环境必须有硬性拦截机制，不能靠人自觉。

---

一、分支与环境强绑定，单向流转不回头

把 Git 分支、Bundle target、物理工作区三者锁死，形成固定晋升路径：

• feature/* → dev target → 共享开发工作区，推就部署，无需审批
• main → staging target → 类生产数据子集，合并自动部署
• release/* tag → prod target → 生产工作区，仅手动审批通过才放行

feature/xyz → PR → main (staging 自动部署) → tag v1.4.0 → prod (人工确认)

这套骨架定下来后，所有后续 gate 才有了挂载点。

---

二、十道关卡，任意一道挂了就停

Gate 1-2：静态检查 + 密钥扫描

black --check . && ruff check .
sqlfluff lint ./sql --dialect databricks
detect-secrets scan --baseline .secrets.baseline

语法风格和密钥泄露在本地就拦住，别等到 CI 报错再改。

Gate 3：单测不碰集群

用 chispa + pytest 跑 PySpark 本地 session，覆盖率门槛 80%：

pytest tests/unit --cov=src --cov-fail-under=80

十几秒跑完，快才是正义。

Gate 4：Bundle 语义校验

databricks bundle validate -t staging

把 YAML 拼写错误、资源引用缺失在部署前暴露。

Gate 5：临时工作区跑真集成测

databricks bundle deploy -t dev
databricks bundle run integration_test_job -t dev
python scripts/assert_output.py
databricks bundle destroy -t dev --auto-approve

部署 → 跑 Job → 断言产出 → 销毁，全自动。这道 gate 抓出过「本地跑通、集群挂掉」的资源配额问题不下五次。

Gate 6：数据契约硬拦截

Delta Live Tables 里直接写期望，失败即熔断：

@dlt.expect_or_fail("valid_id", "id IS NOT NULL")
@dlt.expect_or_drop("valid_amount", "amount >= 0")

expect_or_fail 等同于代码层面的单测红了，脏数据根本进不了 trusted 表。

Gate 7：权限即代码

Unity Catalog 授权写在 databricks.yml，随 PR 一起评审：

resources:
  grants:
    - object: catalog/analytics.sales
      principal: "data-engineers"
      privileges: ["SELECT", "MODIFY"]

再也没人偷偷在 UI 里加权限忘记同步回仓库。

Gate 8：生产部署唯一人工关卡

GitHub Environment 配置 required reviewers，流水线跑到这步直接暂停，等 Tech Lead 点 Approve。这是全流程唯一的 Human-in-the-loop。

Gate 9：金丝雀分批放量

新 Bundle 不直接覆盖所有生产 Job。先部署一个金丝雀 Job（非核心管道或单分区数据），观察一轮调度周期无异常，再把剩余 Job 切过去。

Gate 10：部署后冒烟测 + 自动回滚

生产部署完成立刻跑一个只读冒烟 Job，校验关键表行数、关键指