发布不该像每月一次的赌博
很多团队的发布是这样的：攒一个版本，挑个周末，一群人盯着屏幕，祈祷别出问题。一旦出事，半夜起来救火。这种状态下，团队会本能地害怕改动，越改越慢。
软件发布的成熟方向，恰恰相反：把上线拆成小步、加上门禁和回滚，让它变成一件随时可以做、出问题能立刻退回去的平常事。
好的发布体系，不是让你永远不出问题，而是出问题时你能分钟级退回去。
本文核心知识点
- 语义化版本主.次.补丁三段号，一眼看出改动大小。
- 发布门禁测试、扫描、检查全绿才允许上线。
- 灰度先放给一小部分用户，观察没问题再放量。
- 快速回滚出问题能一键退回上一个稳定版。
- 更新日志清楚记录这版到底改了什么。
语义化版本号：让版本号自己说话
版本号如果只是 1.0、1.1、1.2 这样一路涨，没人知道这一版到底改了多大。语义化版本用三段数字让版本号自己说明问题。
| 段位 | 什么时候加一 | 对用户的含义 |
|---|---|---|
| 主版本 | 做了不兼容的大改动 | 升级前要留意变化 |
| 次版本 | 新增了向后兼容的功能 | 多了些好用的新东西 |
| 补丁版本 | 只修了向后兼容的小问题 | 可以放心直接升级 |
# 语义化版本号读法（主.次.补丁）
1.4.2 —— 一次常规的修补
1.5.0 —— 新增了功能，但兼容老用法
2.0.0 —— 不兼容旧版，升级前要评估
# 看到号就知道该不该紧张，不用去翻一堆说明。把版本号规则统一，团队、用户、运维对「这版有多大」就有了共同语言。
发布门禁：没通过就别上线
发布门禁是一道自动把关的关卡：所有该过的检查都绿了，才允许这一版进入发布流程。它把「别合坏代码」从人的自觉，变成系统不让它过。
- 全套测试通过：有一条红就拦住。
- 构建产物可复现：能稳定打出可部署的包。
- 漏洞与扫描：依赖、镜像有高危问题直接标红。
- 必要的人工评审：关键改动有人看过一眼。
# 发布前自动流水线（示意）
跑测试 # 一条红就拦下
打包 # 产出固定版本号的产物
扫描 # 依赖与镜像高危问题
部署到预发 # 先在类生产环境验证
门禁通过后才允许发布
# 门禁是硬规则，不靠发布当天谁来盯着。门禁的意义，是让「带病上线」这件事在流程上就不发生，而不是上线后再补救。
灰度发布：先放一小部分人用
新版本一上来就推给全部用户，风险全压在一次发布上。灰度是反过来：先放给一小部分用户，观察指标没问题，再逐步扩大。
| 阶段 | 放给多少人 | 看什么 |
|---|---|---|
| 内部验证 | 自己团队 | 基本功能能不能跑通 |
| 小流量 | 少量真实用户 | 错误率、性能有没有异常 |
| 逐步放量 | 按比例扩大 | 指标稳定再继续放大 |
| 全量 | 全部用户 | 确认无问题后放开 |
灰度让一次发布的影响面始终可控，真出问题也只有一小部分人受影响。
出问题怎么快速回滚
再小心也会出问题。发布体系的兜底，是出问题时能快速退回上一个稳定版本，而不是熬夜现场修。
- 每一次发布都打了版本标签，上一个可用版随时找得到。
- 回滚是一次标准操作，不是临时手忙脚乱的抢救。
- 数据库改动要兼容老版本，否则回滚会被数据困住。
# 回滚的理想状态（示意）
发现新版本错误率异常
→ 停止继续灰度放量
→ 切回上一个稳定版本
→ 服务在几分钟内恢复
→ 再从容地排查根因
# 回滚要快，是因为它本来就是设计好的一步。回滚不是失败，而是发布体系里预设好的安全阀。
更新日志：让人知道这版改了什么
每次发版都该有一份清楚的更新日志：这一版修了什么、加了什么、有没有要注意的变化。它是给用户、给运维、给未来的自己看的。
- 新增：这版加了哪些用户能感知的能力。
- 修复：解决了哪些已知问题。
- 变更：有没有不兼容、需要提前知道的改动。
更新日志不需要华丽，但要诚实、可读。下次出问题时，它往往是最快定位「哪版引入的」的线索。
把发布变成日常而非仪式
当版本号规则、发布门禁、灰度和回滚都齐备，发布就不再是每月一次需要动员全员的大动作，而是随时可以做的普通操作。
- 敢小步发布，因为每一步都有门禁和回滚兜底。
- 团队不再害怕改动，产品迭代速度自然就快了。
- 出问题时，大家第一反应是回滚和排查，而不是互相追责。
发布体系的终极目标，是让团队敢于、也能够频繁而安稳地把价值送到用户面前。当上线不再像赌博，整个团队的节奏都会轻松下来。