2. Databricks工作区与开发环境标准化
持续交付的第一道门槛不是流水线，而是“环境能不能被复现”。如果每位工程师的 Workspace 目录结构不同、Repos 挂载方式不同、集群参数靠口头约定，那么同一份 Notebook 在 A 的机器上能跑、在 B 的机器上失败，CI 里再跑一次又是第三种结果。本节的目标是把 Workspace 布局、Repos 与 Git 集成、集群策略、个人与共享环境隔离这四件事固化成可复现的开发基线，让“本地能跑”与“流水线能跑”指向同一套定义。
一、Workspace 布局：用目录承载生命周期
Workspace 是 Databricks 中组织 Notebook、文件、Repos 和实验的根容器。标准化的第一步是让目录结构与代码生命周期对齐，而不是按个人习惯随意堆放。推荐采用“共享区 + 个人区”双根布局：/Shared 下按项目或数据域划分，存放团队共用的 Notebook、库和配置；/Users/<email> 下只放个人临时探索内容，禁止作为交付物来源。
在 /Shared 内进一步区分三类路径：/Shared/<domain>/repos 用于挂载 Git 仓库，/Shared/<domain>/jobs 存放作业定义与调度入口，/Shared/<domain>/libs 存放共享的 wheel 或初始化脚本。这样做的价值在于：CI/CD 只需要关注 repos 与 jobs 两个路径，个人目录不进入发布范围，避免“某人本地改了一版”被误发布。
retail-analytics，避免空格和中文，减少路径在 CLI、API 和 CI 脚本中的转义问题。二、Repos 与 Git 集成：让代码有唯一来源
Databricks Repos 把 Git 仓库直接映射到 Workspace 路径，支持分支切换、拉取和提交。标准化的关键是“一个仓库对应一个 Repos 挂载点”，并统一使用服务主体或团队凭据，而不是个人 PAT。典型配置如下：
# 通过 Databricks CLI 创建 Repos 挂载（示例）
databricks repos create \
--url https://github.com/example/retail-analytics.git \
--provider gitHub \
--path /Shared/retail-analytics/repos/retail-analytics
挂载后，开发者在 Workspace 中直接编辑该路径下的 Notebook，提交即回到 Git。这里要建立两条纪律：第一，生产作业只允许引用 Repos 路径，不允许引用 /Users 下的个人副本；第二，分支策略与发布策略绑定，例如 main 对应生产、release/* 对应预发、feature/* 对应开发。这样“代码在哪、哪个分支对应哪个环境”就是确定的，而不是靠记忆。
三、集群策略：把资源规格变成可审计的约束
集群策略（Cluster Policy）是管理员下发的 JSON 约束，用来限制用户创建集群时可选的节点类型、自动伸缩范围、Spark 配置和标签。它解决的是“每个人自建集群、规格各异、成本不可控”的问题。一个面向持续交付的策略应至少固定四类参数：运行时版本、节点类型、自动终止时间和标签。
| 策略字段 | 示例值 | 作用 |
|---|---|---|
spark_version | 13.3.x-scala2.12 | 统一运行时，避免依赖漂移 |
node_type_id | Standard_DS3_v2 | 限制规格，控制成本 |
autotermination_minutes | 30 | 空闲自动释放 |
custom_tags | project=retail, env=dev | 成本归属与审计 |
策略通过 databricks clusters create 或 UI 应用后，用户只能在允许范围内选择。对于作业集群，建议使用“作业集群 + 策略”而非“全用途集群”，因为作业集群随作业生命周期创建和销毁，天然适合 CI/CD 的短时执行。
四、个人与共享环境隔离：边界要可验证
隔离不是靠约定，而是靠权限和路径共同保证。个人环境使用 /Users/<email> 与个人集群，允许自由实验；共享环境使用 /Shared/<domain> 与策略约束下的共享集群或作业集群，只允许通过 Repos 和发布流程变更。权限上，共享目录对开发者给 CAN_RUN 或 CAN_EDIT，对生产服务主体给 CAN_MANAGE_RUN，避免个人凭据进入生产路径。
下面这张图把四类要素组织成一条“开发基线”关系：Workspace 布局提供路径，Repos 提供代码来源，集群策略提供资源约束，隔离规则提供权限边界，四者共同支撑可复现的持续交付。
五、把基线落到可执行的检查项
标准化不是一次性配置，而是每次发布前可验证的检查。建议在仓库根目录放置一份 baseline.md，并在 CI 中加入以下校验：Repos 路径是否指向 /Shared/<domain>/repos；作业定义是否引用 Repos 路径而非个人路径；集群是否使用指定策略；标签是否包含 project 与 env。这些检查可以用 Databricks CLI 或 REST API 实现，例如列出作业并检查其 notebook_path 前缀。
一个常见的失败模式是：开发者在个人目录调试通过后，直接把 Notebook 复制到共享目录，但依赖的库版本来自个人集群。正确做法是把依赖写入 requirements.txt 或 pyproject.toml，由作业集群在启动时安装，并在策略中固定运行时版本。这样“环境”由代码和策略共同定义，而不是由某台机器定义。
完成以上四件事后，团队就拥有了一条可复现的开发基线：路径确定、代码来源确定、资源规格确定、权限边界确定。后续的持续交付流水线只需要在这条基线上做“构建—测试—部署”，而不必反复处理环境差异带来的噪声。