持续集成实践之持续交付的五个核心实践(3)

　　除了能够做增量式地功能交付以外，特性开关还有另一个重要的用途。万一遇到未预期的负载过高，它们可以优雅地对在线服务进行降级(degrade)，比如通过关闭资源密集型的特性，如推荐引擎。另外，当发布出了问题时，它们也可以让你马上关闭存在问题的特性，相当于做了一次回滚操作。

　　Conclusions

　　一种常见的软件项目失败模式是Don Reinertsen在他的书《The Principles of Product Development Flow: Second Generation Lean Product Development (Celeritas, 2009)》所说的“large batch death-spiral”，而product owners为了试图确保产品的成功，在项目进行中，增加越来越多的范围，从而导致成本显著增加，工期明显拖长。

　　持续交付让团队大幅度减少发布高质量软件的transaction成本，所以你可以更频繁地发布，产品团队从而能够从用户那里得到更加丰富和迅速的反馈。但是，反过来，对于在整个软件交付流程中如何管理工作流，你也需要改变一下思考方式。尤其强调的一点是，假如你正确地实施了持续交付，在用户那里验证新的主意时，技术人员就不再是一种约束了。使用传统的交付流程，则你不得不等上数个星期或都是数月，才能看到你的想法变成软件。通过增量式交付小的功能，并收集反馈，我们可以持续思考：“下一步我们应用做什么?”没有哪个团队达到这种转变后，还想再回到原有的工作方式上。

　　使用传统的交付方法，我们必须细心地挑选我们想实现哪些想法，因为软件交付的过程成本太高了。当然，那种审查流程也并不是基于真实数据的。然而，通过持续交付，我们就有了我的同事Darius Kumana所说的一种 ”创新失败的安全气囊”。在系统 we can try crazily innovative ideas cheaply and safely at any stage in the evolution 演进的过程中，可以用廉价且安全的方式尝试那些异想天开的创新想法，通过仅将其开放给少量用户组，缓解可能失败的风险。持续交付通过大幅度减少软件发布的风险来解放我们，把分析师带回他们本来的位置——全力创新。

原文转自：http://www.ltesting.net