持续交付模式(4)

　　修正补丁(hot fix)如何处理?

　　所有这些场景中，我们都没有提到修正补丁的概念。这是有意为之，如果遵循持续交付的思想和理念，是没有所谓的修正补丁的。一旦变更进入集成环境，它们就会很快进入生产环境。在这个理论下，不需要修正补丁，只有正常的bug修复，其优先级偶尔会超过功能特性的开发。

　　然而，现实世界不是完全由理论指导的。功能常常会停滞在QA阶段，其时间超过预期，要么是质量问题，或者仅仅是因为它们的规模。与之类似，生产部署也可能延迟，因为业务需要，比如合同强制要求，或是早已公之于众的特定日期升级计划。类似事件发生时，修正补丁就有必要了。此时，最佳方案是抛开流程，完成工作优先。不要让形式成为公司和客户不必要的负担。一旦尘埃落定，危机解决，就可以开始研究问题发生的根本原因了。

　　持续交付的目标，不是要让修正补丁更易于处理，而是要制定出编码和测试的标准，消除对修正补丁的需要。每次流程失败的时候，就是你学习如何改进代码标准和测试实践的机会，避免重大bug再次发生。同样地，这也能为你提供理由，检查日程表制定方针中的缺陷，看看是什么导致流程的停滞和问题。如果无法同时在这两方面聚焦，你就永远不能保证所有的bug修复都可以通过严格控制的流程。

　　简而言之，持续改进是任何形式的持续交付的根本组件。

　　关于作者

　　Jonathan Allen从2006年开始就为InfoQ撰写新闻报道，目前是.NET领域的首席编辑。如果您希望为InfoQ编写新闻或是有价值的文章，请通过jonathan@infoq.com联系他。

原文转自：http://kb.cnblogs.com/page/117932/