版本发布流程设计

# 版本发布流程设计

语义版本号、发布checklist、回滚方案——发布不是点一下按钮

# 一、语义版本号——不是 1.0.0 就完了

MAJOR.MINOR.PATCH
 主版本.次版本.修订号

1.2.3 → MAJOR=1, MINOR=2, PATCH=3

什么时候加 MAJOR（主版本）？
  → 不兼容的 API 变更。旧客户端不升级就挂了。
   例：1.9.5 → 2.0.0（"支付接口参数结构变了，旧版本不兼容"）

什么时候加 MINOR（次版本）？
  → 新增了向后兼容的功能。旧客户端不升级也没事，但升级才能用新功能。
   例：1.2.3 → 1.3.0（"新增了人脸登录功能"）

什么时候加 PATCH（修订号）？
  → 向后兼容的 bug 修复。
   例：1.2.3 → 1.2.4（"修复了支付页面在 iPhone SE 上显示不全"）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 工程师最容易踩的版本号坑

坑 1：1.0.0 之前的版本号规则不同
  0.x.y 阶段：MINOR 变 = 破坏性变更，PATCH 变 = 新功能/修 bug
  因为 0.x 本身就是不稳定版本。

坑 2：忽略依赖库的版本号
  你的项目是 1.0.0，但你依赖的一个 SDK 从 2.x 升到 3.x（不兼容）——
  你只改了 PATCH（1.0.0 → 1.0.1），但从用户角度看这就是破坏性变更。

坑 3：版本号不写在代码里
  用户反馈 bug，你问"什么版本？"他说"最新的"。
  你的 App 设置页、API 响应头、日志里——至少一个地方要自动输出当前版本号。

1
2
3
4
5
6
7
8
9
10
11

# 二、发布前的检查清单

发布 Checklist（每一条都有人确认，不是"我感觉可以了"）：

□ 代码冻结：release 分支已创建，不再往 release 里合功能
□ 自动化测试：单元测试 + 集成测试全绿（不是"大部分绿"）
□ 回归测试：核心流程手动跑一遍（注册→登录→主要操作→退出）
□ 性能基准：P99 延迟和上一版本对比——有没有退化？
□ 崩溃率：staging 环境跑 Monkey/UI 自动化退出，崩溃率为 0
□ 依赖检查：所有依赖库版本是明确的（没有 SNAPSHOT / latest）
□ 数据库迁移脚本：已 review，有回滚脚本
□ 配置变更：新增/修改的配置项已同步到所有环境
□ 回滚方案：确认过回滚步骤能跑通（不是"应该没问题"）
□ 通知：相关人员（客服、运营、下游团队）已知道发布时间和影响范围

1
2
3
4
5
6
7
8
9
10
11
12

工程师的发布底线：如果"回滚方案"这一条你勾了但没实际跑过——等于没勾。

# 三、灰度发布——先让 1% 用户当小白鼠

不要全量发布 → 灰度是保命的手段

标准灰度节奏：
Step 1：内部灰度（公司员工，1 小时）
  → 你刚发的版本，自己先用。如果有明显 bug，也能快速发现。

Step 2：1% 外部用户（观察 2-4 小时）
  → 监控：崩溃率、接口错误率、关键业务流程转化率
  → 和上一个版本对比——任何指标恶化了 30%+ → 停止灰度

Step 3：10% → 50% → 100%（每一步至少观察 2 小时）
  → 不跳过任何一步。你觉得"1% 没问题 50% 肯定没问题"——
    上次有人这么想，结果是 1% 的用户恰好没用那个功能，50% 的时候大量崩溃。

1
2
3
4
5
6
7
8
9
10
11
12
13

灰度期间你能做什么：

盯着监控面板，别去写新代码
客服通道保持畅通——灰度用户的反馈是第一批信号
回滚按钮（或开关）确认可用——不是 "应该可以回滚"，是真的点过

# 四、回滚——发布不可怕，回不了滚才可怕

# 4.1 回滚的三种方式

方式	怎么做	适合场景	耗时
Feature Flag	关掉有问题的功能开关	新功能出问题，老功能正常	秒级
蓝绿部署	切流量回旧集群	整个版本有问题	分钟级
重新部署	用旧版本包重新发布	没有蓝绿环境	5-15 分钟

Feature Flag 是最快的保险。 任何新功能上线都应该配一个开关。如果这个功能出了问题——不是回滚整个版本，而是关掉这一个功能。

# 4.2 回滚决策——什么时候必须回滚

必须立即回滚的信号：
□ 崩溃率 > 基线的 3 倍
□ 支付流程失败率 > 1%（每一秒都在丢钱）
□ 登录/注册不可用（用户进不来）
□ 数据损坏（用户数据被改坏了——不止要回滚版本，还要回滚数据）

可以灰度修复的信号：
□ 某个边缘功能 UI 错位
□ 非核心接口 P99 延迟涨了 50%
□ 部分机型的适配问题（不影响主流程）

1
2
3
4
5
6
7
8
9
10

判断原则：用户的损失已经大于回滚的成本 → 回滚。犹豫的时候问自己：晚 10 分钟回滚，多少用户会受影响？

# 五、发布后——不是发完就下班

发完后 2 小时内必须做的：

□ 核心监控面板盯住——至少看 2 小时
□ 跑一遍核心用户路径（你自己用最新版本走一遍注册→下单）
□ 搜索社交平台——搜你的产品名/App 名，看有没有用户说"更新完就不能用了"
□ 客服渠道——有没有相关投诉突然增多？

发完后 24 小时内：
□ 对比新旧版本的指标：崩溃率、启动时间、关键转化率
□ 如果有灰度测试，对照组和实验组的指标差异确认
□ 写一个"发布后总结"——一句话记下：发了什么、有没有问题、学到了什么

1
2
3
4
5
6
7
8
9
10
11

# 六、小结

发布不是终点——是"你的代码在用户设备上运行"的起点。

发布四要素：
1. 版本号     → 遵循语义版本规范，MAJOR.MINOR.PATCH 各有明确的含义
2. Checklist  → 发布前逐条确认，不是凭感觉
3. 灰度       → 1% → 10% → 50% → 100%，不跳步
4. 回滚方案   → Feature Flag 是最好的保险，回滚比硬扛要勇敢

1
2
3
4
5
6
7

行动清单：

[ ] 检查你们项目是否有 Feature Flag——没有的话给下一个新功能加一个
[ ] 下一个版本发布前，把 Checklist 打印出来（或建一个 issue 模板），逐条勾
[ ] 实际跑一次回滚流程（在 staging 环境）——确认回滚步骤没有过时

#发布

上次更新: 2026/06/15, 14:32:53

← Scrum框架入门指南代码分支管理策略→