概述
WeData 提供多种发布模式来实现开发与生产环境的隔离，满足不同安全等级和操作效率的需求。本文帮助您了解各发布模式的核心区别、适用场景和隔离能力，以便根据实际业务需求选择合适的方案。
注意：
不同发布模式对项目模式、环境部署有不同的前提要求，请在环境搭建前确认适合的发布模式。
发布模式总览
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）管控发布节奏
需要跨项目甚至跨账号的灵活部署能力
相关文档
发布中心
跨项目克隆
迁移助手
