知识卡片
高频发布反而降低单次发布风险
内容
面向用户的组件被鼓励尽可能频繁地重新构建和发布：发布频率越高，每次发布之间累积的变更量就 越小，测试和调试也越简单，出问题时需要排查的改动集合更小，回滚代价也更低。”测试通过即发布” 模式把这个逻辑推到极致：只要通过全部测试就自动部署，不再攒一批变更发大版本。真正决定发布 风险的是单次变更量而非发布次数，这与[[分层服务水平把成本选择权交给用户]]背后拆分而非一次性 满足需求的思路相通。
参考来源
- 位置：《SRE：Google运维解密》第8章《发布工程》"追求速度"一节（源文件：_epub-src/OEBPS/Text/0008_0006.xhtml）
- 结论依据：原文指出面向用户组件被鼓励频繁构建发布，因为频繁发布使版本间变更量减少、测试调试更简单，并举"测试通过即发布"（Push On Green）作为极致案例。
- 原始内容：“面向用户的软件组件……重新构建非常频繁……我们同时也认为频繁的发布可以使得每个版本之间的变更减少。这种方式使得测试和调试变得更简单……还有的团队采用一种‘测试通过即发布’（Push On Green）的发布模型，也就是说，部署每个通过所有测试的版本。”