部署与发布的区别
把「部署」与「发布」拆成两件事：部署是代码进入环境、随流水线自动执行；发布是对用户生效的时机与范围，由开关或流量规则决定。先部署默认关闭的功能，观察稳定后再放开，部署频率与业务时机因此解耦，回滚也从「回滚制品」变成「关闭开关」，操作代价小得多。
基本信息
| 部署 | 制品安装到环境、随流水线自动执行 |
|---|---|
| 发布 | 对用户生效的时机与范围 |
| 解耦手段 | 功能开关、流量权重、用户白名单 |
| 收益 | 部署不再承担业务时机压力，回滚更快 |
| 约束 | 数据库结构变更要与新旧两个版本兼容 |
典型使用场景
- 暗发布：新功能先上线但仅内部可见，观察资源与日志。
- 灰度放开：按用户比例或地区逐步打开开关。
- 紧急关闭：出问题时关开关止血，不必回滚制品。
- 解耦节奏：部署跟随流水线，发布跟随业务窗口。
- 降低回滚：多数问题用开关处理，回滚是最后手段。
示意
示意
# 部署完成但功能关闭
FEATURE_NEW_CHECKOUT=false ./deploy.sh
# 观察后再放开
FEATURE_NEW_CHECKOUT=true ./deploy.sh --reload-config两者对照
| 维度 | 部署 | 发布 |
|---|---|---|
| 定义 | 制品安装到环境 | 对用户生效的时机与范围 |
| 触发 | 流水线自动执行 | 开关、流量、名单 |
| 失败处理 | 回滚制品或前滚 | 关闭开关 |
| 频率 | 可每日多次 | 按业务节奏决定 |
解耦后「发布失败」更多是业务开关未达预期，可直接关闭开关恢复，不必回滚制品。
开关要有唯一入口与审计：散落在各处的配置读取会让「关闭」动作遗漏某处。
数据库变更天然难以「未发布」：结构变更要设计成与新旧两个版本同时兼容。