Release

解决什么问题：让新代码安全、可控、可逆地到达生产环境—— 没有 release 工程 = "上线 = 祈祷"； 有了 release 工程 = "上线 = 一个可重复、可回滚、可验证的工程动作"。

它是什么

Release（发布） 是把代码从开发环境推进到生产环境的工程过程—— 包括打包、测试、部署、灰度、监控、回滚。

开发 ──→ 构建 ──→ 测试 ──→ 部署 ──→ 灰度 ──→ 全量 ──→ 监控
  │        │        │        │        │        │        │
  ↓        ↓        ↓        ↓        ↓        ↓        ↓
commit   镜像/包   自动化    蓝绿/    1%→5%   100%    实时
        制品化    验证    滚动发布  →50%            验证
                                          │
                                          ↓
                                       异常 → 回滚

SE@G Ch 24： "Continuous Deployment is not just about automating releases; it is about making releases so routine that they are no longer a special event — they are just another part of the workflow."

V2 视角（V2 B5 + B7）：Release 不是一次性动作，是持续演化的载体—— 好的 release 工程让"改变"成为日常，而不是"大事件"——降低演化的阻力。

关键属性

属性	值/含义
可重复	同一份代码多次发布，结果一致
可回滚	出问题能在分钟级回滚到上一版本
灰度	渐进式发布（1% → 5% → 50% → 100%）
自动化	从 commit 到生产尽量减少人工介入
可观测	发布过程中的每一步都可监控
可审计	谁在什么时候发布了什么
低风险	单次发布的爆炸半径小
高频	发布频率越高，单次风险越低

怎么用

场景 1：发布模式选择

模式 1：蓝绿发布（Blue-Green）
  - 两套完整环境（蓝 / 绿）
  - 流量瞬间切换
  - 优点：切换快、回滚快
  - 缺点：资源翻倍

模式 2：滚动发布（Rolling）
  - 逐批替换实例
  - 优点：资源不浪费
  - 缺点：回滚慢、新旧共存

模式 3：金丝雀（Canary）
  - 小流量验证新版本
  - 优点：风险最小
  - 缺点：验证周期长

模式 4：Feature Flag
  - 代码已部署，特性按配置开关
  - 优点：发布和特性解耦
  - 缺点：配置复杂度

选择：
  - 核心服务：蓝绿 + 金丝雀（银行级）
  - 普通服务：滚动 + 金丝雀（互联网常态）
  - 频繁迭代：Feature Flag（互联网高级）

场景 2：标准发布流水线

1. 开发者 push 代码
   ↓
2. CI 触发：编译 + 单元测试
   ↓
3. 构建镜像 / 制品
   ↓
4. 部署到预发环境
   ↓
5. 集成测试 + 性能测试
   ↓
6. 部署到生产（金丝雀 1%）
   ↓
7. 监控金丝雀（5-15 分钟）
   │
   ├─ 指标正常 → 扩大 5% → 10% → 50% → 100%
   └─ 指标异常 → 自动回滚 + 告警
   ↓
8. 全量发布完成
   ↓
9. Postmortem（如果出过问题）

场景 3：发布失败的处理

典型失败模式：
  1. 健康检查失败（启动慢 / 端口没起）
  2. 启动后立刻崩溃（配置错误 / 依赖缺失）
  3. 启动正常但 P99 飙升（性能回归）
  4. 启动正常但错误率上升（功能回归）
  5. 启动正常但业务指标恶化（隐性问题）

处理流程：
  - 检测：监控告警自动触发
  - 决策：人工确认 / 自动决策
  - 动作：回滚 / 扩容 / 限流
  - 复盘：Postmortem（特别是隐性回归）

SE@G Ch 24：发布失败不可怕，可怕的是"无法回滚"——
任何 release 都必须保证"秒级回滚能力"。

场景 4：发布频率与质量的平衡

传统模式：
  - 每月 1 次大版本发布
  - 单次发布改动大（> 100 commit）
  - 发布失败率高（10-20%）
  - 团队压力极大

现代模式：
  - 每天 10+ 次发布
  - 单次发布改动小（1-5 commit）
  - 发布失败率低（< 1%）
  - 团队压力小

关键洞察：
  高频小发布 ≠ 简单堆叠
  - 需要完整的自动化流水线
  - 需要完善的灰度机制
  - 需要快速回滚能力
  - 需要 Feature Flag 支撑
  - 需要 Postmortem 文化

EDM Ch 16：发布频率 = 工程成熟度的指标。

常见误区

1. "发布 = 上线动作"——错。发布是完整生命周期（构建→测试→部署→灰度→监控→回滚）
2. "灰度 = 慢"——错。灰度比"全量后回滚"快得多——出问题秒级回滚比修问题快
3. "频繁发布 = 不稳定"——错。反过来了——频繁发布迫使自动化，回滚能力反而强
4. "回滚 = 失败"——错。回滚 = 正常工具，承认"新版本可能错"是工程成熟的标志
5. "代码合并 ≠ 发布"——错。解耦——代码合并到主干（持续集成）和发布到生产（持续部署）应当解耦

关键洞察

Release 的目标不是"上线"——是"安全、可控、可逆地改变生产"。

好的 release 工程让"改变"变得平淡无奇： 发布 = 一次普通的 git push + 自动流水线。 没有仪式感，没有"上线日"——这才是工程成熟的标志。

相关链接

• A/B 测试——发布后验证
• 技术债——发布节奏 vs 还债节奏
• 数据驱动——发布效果度量
• 闭环反馈——发布是闭环的一环
• [V3 涌现之时] · 演化——发布是演化的载体
• [V3 涌现作为] · 反馈——发布验证靠反馈