发布与部署的区别
发布是让用户可用新功能，属于业务视角；部署是把代码放入环境，属于技术视角。两者解耦后可以做到部署完成但暂不发布：用特性开关控制可见性，用暗启动验证后端逻辑。好处是风险分段承担——部署失败影响技术环境，发布决策可按业务节奏与观察结果推进，业务指标异常时先关开关止血，不必整体回滚到旧版本。
基本信息
| 发布 | 业务与用户视角，可分批灰度 |
|---|---|
| 部署 | 技术视角，可完全自动化 |
| 解耦手段 | 特性开关、暗启动 |
| 关键收益 | 风险分段、止血更快 |
| 治理要求 | 开关要有生命周期管理 |
| 关联实践 | 发布管理、部署管理、变更使能 |
典型使用场景
- 大型功能上线：先部署代码，业务确认后再开启开关
- 后端逻辑验证：暗启动跑新逻辑但不影响输出，对比结果
- 业务指标异常：关闭开关即可止血，无需回滚部署
- 多环境多版本：同一制品在不同环境先后部署，按需发布
- 灰度放量：按用户群或比例逐步开启功能
- 节奏与业务对齐：市场活动与功能可见性分开安排
解耦示例
解耦示例
周一：部署新结算代码（开关关闭，用户无感）
周三：向 5% 用户开启开关并观察业务指标
周五：全量开启；异常则关闭开关止血
清理：功能稳定后移除开关与旧代码路径两者对照
| 维度 | 发布 | 部署 |
|---|---|---|
| 视角 | 业务与用户 | 技术与环境 |
| 用户可见性 | 直接影响用户 | 可先隐藏 |
| 失败处理 | 关闭开关或回退版本 | 回滚部署或重新下发 |
| 节奏 | 按业务与市场安排 | 按迭代与流水线安排 |
解耦后发布决策成为业务动作，部署成为例行技术动作，两者的审批与责任人也可以分开设计。