软件项目开发全流程 · 第 26 课 · 上线发布：计划、回滚与变更管理
1、上线那天，最怕"临时改一下"
发布窗口定在晚上 10 点。临上线前，有人提议："顺手把那个小 bug 也带上吧？"——于是发布内容从 5 个改动变成 6 个。上线后出事，没人知道是哪个改动引起的，回滚就退掉全部，连本来没问题的也一起退。
发布的敌人不是技术，是"不可控的变更"。 本课讲：怎么把一次发布，变成一件有清单、有预案、有审批、可追溯的常规动作。
2、发布 ≠ 部署
先把两个词分清：
- 部署（Deploy）：把制品装到环境里，是技术动作。
- 发布（Release）：让用户真正用到新功能，是业务动作。
两者可以解耦（这叫 暗部署 / 功能开关）：
代码早就部署上线了，但功能被开关关着，用户看不到
↓ 确认没问题
在后台把开关打开 → 功能对用户"发布"功能开关（Feature Flag）的好处：
- 部署与发布解耦：代码合了但先不启用，风险可控。
- 秒级回滚：出问题关开关即可，不用回滚代码。
- 支持灰度：按用户/比例逐步放量。
- A/B 测试：不同用户看不同方案，用数据决策。
if flags.is_enabled("new_checkout_flow", user):
return new_checkout(user)
else:
return old_checkout(user)但要还债：开关用完要及时清理，否则代码里堆满"永久开着的开关"，成了新的技术债（第 30 课）。
3、发布检查清单（Release Checklist）
一张随时能过的清单，胜过临场发挥。 典型清单：
【发布前】
□ 所有 P0/P1 bug 已修复
□ 制品已构建、已推仓库、版本号正确
□ 变更清单（Changelog）已写好，包含影响范围
□ 数据库变更已评估（是否向后兼容？能否回滚？）
□ 配置/密钥已就位（各环境）
□ 回滚方案已确认并演练过
□ 监控/告警已就绪（能发现异常）
□ 干系人已通知（受影响的人知道要发布）
【发布中】
□ 按流水线部署，观察每一步
□ 部署后跑冒烟测试（核心路径）
□ 观察关键指标 5~15 分钟（错误率、延迟、QPS）
□ 无异常 → 逐步放量（灰度 → 全量）
【发布后】
□ 确认核心指标正常
□ 更新发布记录（谁、何时、发了什么版本）
□ 通知干系人"发布完成"
□ 有问题 → 立即按预案回滚"变更清单 + 影响范围" 是核心：让所有人清楚这次到底动了什么。
4、回滚：最坏情况下的安全带
回滚预案要在发布前就想好，别等出事了才临时决定：
| 回滚方式 | 速度 | 适用 | 注意 |
|---|---|---|---|
| 功能开关关闭 | 秒级 | 有开关的功能 | 最快、最安全 |
| 切回旧版本制品 | 分钟级 | 无状态服务 | 需保留旧制品 |
| 流量切回旧环境 | 秒级 | 蓝绿部署 | 最干净 |
| 数据库回滚 | 慢/难 | 结构变更 | 尽量设计成不需回滚 |
什么情况必须回滚（不要犹豫）：
- 核心功能不可用（登录、支付）
- 错误率飙升 / 严重性能退化
- 数据错误或丢失
- 出现安全事件原则：回滚是第一优先，不是排查。先止血（回滚），再慢慢找原因。等"再看一眼"往往错过最佳时机。
5、变更管理：让变更可控、可追溯
变更管理（Change Management） 不是"官僚审批"，而是让每次生产变更都：有记录、有评估、有批准、有回滚。
变更分类：
| 类型 | 例子 | 流程 |
|---|---|---|
| 标准变更 | 常规代码发布（低风险） | 预批准，走流水线即可 |
| 普通变更 | 配置调整、新功能上线 | 需评审/审批 |
| 紧急变更 | 线上故障抢修 | 快速通道，事后补审 + 记录 |
变更记录应包含：谁（Who）、何时（When）、改了什么（What）、为什么（Why）、怎么回滚（How）。这正是发布记录 / 变更日志的价值。
现代做法不是"加重审批"，而是"收紧技术护栏 + 自动化"：
- 变更走自动化流水线（谁能略过流水线？基本没有）。
- 高风险变更加审批门，低风险自动放行。
- 所有变更自动记录（部署日志 + git 历史 + changelog）。
6、保持"小步快跑"
发布最大的风险来自大批量变更。很多团队用一个反直觉的原则：
想发得稳，就要发得勤。
因为：
- 每次变更小 → 出问题容易定位（就这几个改动）。
- 回滚代价小 → 退一小步而已。
- 发布成了常态 → 团队不紧张，流程顺畅。
- 反馈快 → 用户早受益，早发现问题。
反模式：攒三个月功能一次性发布 → 巨大风险、巨大回滚代价、漫长测试。
配套：用 功能开关 + 增量发布，让"代码持续合并"和"用户逐步感知"两不误。
7、常见误区
| 误区 | 问题 | 正解 |
|---|---|---|
| 上线前临时加需求 | 变更不可控、难定位 | 冻结变更，新品下个版本 |
| 没有回滚案 | 出事硬扛 | 发布前必演练回滚 |
| 出事先排查后回滚 | 错过止血时机 | 先回滚止血，再排查 |
| 部署=发布 | 无法解耦风险 | 用功能开关解耦 |
| 变更不记录 | 事故无法复盘 | 发布记录 + changelog |
| 攒大招一次性发 | 风险集中 | 小步快跑、增量发布 |
8、动手实验 🎯
任务：为贯穿项目「团队任务清单」设计一次"教科书式"发布。
- 写发布检查清单：为你项目写一份三阶段（前/中/后）清单。
- 写变更日志：用 Keep a Changelog 格式，为
v0.2.0写一份 changelog（新增/修复/破坏性变更）。 - 接功能开关：给一个新功能加开关，实现"先部署、后开启"。
- 设计回滚脚本：一条命令回到上一版本，并实际演练一次（在测试环境）。
- 模拟一次发布事故：故意部署一个坏版本，练习"先回滚止血"，记录你的处置时间。
- 做一次变更记录：把这次发布填进变更记录表（Who/When/What/Why/How）。
- 反思：你更喜欢"半年发一次大的"还是"每周发几次小的"？各自的隐性成本是什么？
下一课：运维与监控。
9、今天你带走的三句话
- 部署 ≠ 发布：用功能开关把两者解耦，秒级回滚。
- 发布检查清单 + 回滚预案，是每次发布的标配；出事先回滚止血。
- 小步快跑最安全——变更越小，越易定位、越易回滚。
下一课：运维与监控。