概述
注意：不同发布模式对项目模式、环境部署有不同的前提要求，请在环境搭建前确认适合的发布模式。
一、发布模式总览
WeData 支持以下四种发布模式：
| 发布模式 | 功能名称 | 核心特点 |
| 项目内发布（标准模式） | 发布中心 | 同一项目内，通过开发/生产环境隔离实现代码和数据的逻辑隔离 |
| 同账号跨项目发布（跨项目克隆） | 跨项目克隆 | 同一账号下不同项目间克隆任务，实现任务的逻辑隔离 |
| 跨环境发布（导入导出） | 迁移助手 | 不同项目间通过导入导出实现任务迁移，支持跨账号、跨地域 |
| CI/CD | WeData Bundle | 通过 Git + 自动化流水线实现持续集成与交付，支持跨项目、跨账号 |
二、核心差异对比
| 维度 | 项目内发布（标准模式） | 同账号跨项目发布（跨项目克隆） | 跨环境发布（导入导出） | CI/CD |
| 功能名称 | 发布中心 | 跨项目克隆 | 迁移助手 | WeData Bundle |
| 项目模式要求 | 标准模式（DO 隔离模式） | 简单模式 | 简单模式 | 简单模式 |
| 项目数量 | 1 个项目 | 同账号下 2 个及以上项目 | 2 个及以上项目（可跨账号） | 2 个及以上项目（可跨账号） |
| 跨地域支持 | 不支持 | 不支持（仅支持同地域） | 支持 | 支持 |
| 跨账号支持 | 不支持 | 不支持 | 支持 | 支持 |
| 版本管理 | 平台内置版本管理 | 有发布记录，不支持回滚 | 有发布记录，不支持回滚 | Git 版本管理 |
| 自动化程度 | 手动提交发布 | 手动执行克隆 | 手动导出导入 | 自动化流水线触发 |
| 审批流程 | 内置发布审批 | 内置发布审批 | 无内置审批 | 可通过 Git 合并审批实现 |
| 工作流调度模式支持 | 暂不支持 | 暂不支持 | 暂不支持 | 支持 |
三、隔离能力对比
| 隔离维度 | 项目内发布（标准模式） | 同账号跨项目发布（跨项目克隆） | 跨环境发布（导入导出） | CI/CD |
| 网络 | 互通 | 互通 | 物理隔离 | 支持跨项目和跨环境两种模式。隔离情况分别对应跨项目克隆和跨环境发布 |
| 用户账号 | 互通 | 互通 | 物理隔离 | 同上 |
| 计算资源 | 物理隔离 | 物理隔离 | 物理隔离 | 同上 |
| 存储资源 | 物理隔离 | 物理隔离 | 物理隔离 | 同上 |
| 任务 ID | 互通 | 逻辑隔离 | 物理隔离 | 同上 |
| 任务代码/配置 | 逻辑隔离（版本管理） | 逻辑隔离 | 物理隔离 | 同上 |
| 项目成员 | 互通 | 逻辑隔离 | 物理隔离 | 同上 |
| 项目参数 | 逻辑隔离（开发/生产取值不同） | 逻辑隔离 | 物理隔离 | 同上 |
| 执行资源组 | 互通 | 逻辑隔离 | 物理隔离 | 同上 |
| 数据源配置 | 逻辑隔离（开发/生产两套配置） | 逻辑隔离 | 物理隔离 | 同上 |
四、成本与安全对比
| 维度 | 项目内发布（标准模式） | 同账号跨项目发布（跨项目克隆） | 跨环境发布（导入导出） | CI/CD |
| 部署成本 | 低（1 套 WeData + 1 或 2 套引擎） | 低（1 套 WeData + 2 套及以上引擎） | 中高（1 套或多套 WeData + 对应引擎） | 中（1 套或多套 WeData + 2 套及以上引擎 + Git 服务） |
| 安全等级 | 中（数据物理隔离 + 任务逻辑隔离） | 中（数据物理隔离 + 任务逻辑隔离） | 高（完全物理隔离） | 中高（数据物理隔离 + Git 管控） |
五、项目内发布（标准模式）
·部署 1 套 WeData 产品（同集群、同 WeData 同项目）
·部署 1 套或 2 套大数据引擎（如 1 个 EMR 集群创建 2 个数据库，或 2 个 EMR 集群）
·创建 1 个标准模式项目，配置存算引擎的开发环境和生产环境
六、同账号跨项目发布（跨项目克隆）
·部署 1 套 WeData 产品（同集群、同 WeData 平台，双项目隔离）
·部署 2 套大数据引擎（如 2 个 EMR 集群 或 2 个地域的 DLC）
·创建 2 个简单模式项目（1 个开发项目 + 1 个生产项目）
七、跨环境发布（导入导出）
·部署 2 套 WeData 产品（可跨账号、跨地域）
·部署 2 套大数据引擎
·分别创建 1 个简单模式项目
八、CI/CD
·部署 1 套 WeData 产品
·部署 1 套或 2 套大数据引擎
·创建 1 个或 2 个项目（通过 wedata.yml 配置 dev/prod 两个 target）
·搭建 Git 仓库（如 GitLab、GitHub）
·配置 CI/CD 流水线（如 .gitlab-ci.yml）
九、发布模式选择建议
1. 选择项目内发布（标准模式）：
·更注重开发效率，对安全性要求相对一般的情况
·团队中数据开发与运维人员不严格区分，但需要保护生产数据不被开发调试污染
·希望在一个项目内完成开发和发布，操作简单高效，灵活度和效率相对高
·需要内置审批流程管控发布质量
2. 选择同账号跨项目发布（跨项目克隆）：
·需要较好的隔离性，但成本上又相对可控的情况
·开发与运维人员有一定分工，需要项目级别的逻辑隔离
·同账号同地域下管理开发和生产环境
·需要保留完整的任务依赖关系映射能力
·后续有往物理隔离升级的可能
·成本低，不涉及两套部署
3. 选择跨环境发布（导入导出）：
·对安全性要求很高，涉及安全敏感数据的情况
·开发人员不允许接触生产环境，需要完全物理隔离
·从管控、任务、数据三层全隔离
·可接受较高的部署维护成本和较低的操作效率
4. 选择 CI/CD：
·团队熟悉 Git 工作流，希望通过代码版本管理任务配置
·需要自动化的持续集成与交付流程
·希望通过 Git 分支策略（如 dev/prod）管控发布节奏
·需要跨项目甚至跨账号的灵活部署能力
十、相关文档
·简单模式和标准模式
·发布中心
·跨项目克隆
·迁移助手
·CI/CD——持续集成与交付