首页/开发/CI/CD 与发布速查/渐进式交付(Progressive Delivery)
发布策略60 条

渐进式交付(Progressive Delivery)

在持续交付之上叠加「控制暴露范围」:发布不再等价于全量上线,而是结合流量切分、功能开关与自动分析,把变更逐步、可观测地暴露给用户。

CI/CD 与发布速查开发更新于 2026-10-13

渐进式交付是什么

在持续交付之上叠加控制暴露范围:发布不再等价于全量上线,而是结合流量切分、功能开关与自动分析,把变更逐步、可观测地暴露给用户。三要素是渐进放量、自动分析、可回退;常用载体是流量权重、请求头与 Cookie 规则、功能开关。自动化程度高时,指标满足阈值自动晋级,否则自动中止。适用于影响面大、回滚代价高的核心服务。目标是缩小爆炸半径与提前发现问题,不替代发布前的测试与评审。

基本信息

三要素渐进放量、自动分析、可回退
常用载体流量权重、请求头与 Cookie 规则、功能开关
自动化指标满足阈值自动晋级,否则自动中止
适用影响面大、回滚代价高的核心服务
边界不替代发布前的测试与评审

典型使用场景

  • 核心服务发版:用户多、影响大,用渐进放量控制爆炸半径。
  • 夜间与跨时区发布:自动分析替代人工盯盘,降低值守成本。
  • 开关组合:先部署默认关闭、再按需对人群开放。
  • 数据驱动决策:每档停留看指标,达标才继续,不达标自动回切。
  • 与金丝雀的关系:渐进式交付是方法论集合,金丝雀是其中一种流量控制手段。
  • 演练回退:定期演练自动中止与回切路径,确保通道可用。

典型阶梯

典型阶梯
内部用户 到 1% 到 5% 到 25% 到 50% 到 100%
每档停留并核对:错误率、延迟、业务指标、日志告警
目标是缩小爆炸半径与提前发现问题,不替代发布前的测试与评审。
只做流量切换不做自动分析:等于把人工盯盘当成门禁,夜间发布尤其危险。
回切通道要预先演练:没有验证过的回滚等于没有回滚。

易错点

  • 只做流量切换不做自动分析:人工盯盘不可靠,夜间发布尤其危险。
  • 放量阶梯过粗(1% 直接到 100%):观测窗口形同虚设,故障一次性全量暴露。
  • 指标没定义就放量:看什么、阈值多少、谁判断都没写清,放量沦为走流程。
  • 回切通道没演练:需要回退时才发现开关、路由或权限不可用。
  • 把渐进式当纯工具采购:没有观测与回退纪律,工具只是摆设。

数据来源与参考

  • Humble & Farley《Continuous Delivery》第 10 章
  • Argo Rollouts 文档《Concepts》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌