持續交付模式(4)

　　修正補丁(hot fix)如何處理?

　　所有這些場景中，我們都沒有提到修正補丁的概念。這是有意為之，如果遵循持續交付的思想和理念，是沒有所謂的修正補丁的。一旦變更進入集成環境，它們就會很快進入生產環境。在這個理論下，不需要修正補丁，只有正常的bug修復，其優先級偶爾會超過功能特性的開發。

　　然而，現實世界不是完全由理論指導的。功能常常會停滯在QA階段，其時間超過預期，要么是質量問題，或者僅僅是因為它們的規模。與之類似，生產部署也可能延遲，因為業務需要，比如合同強制要求，或是早已公之于眾的特定日期升級計劃。類似事件發生時，修正補丁就有必要了。此時，最佳方案是拋開流程，完成工作優先。不要讓形式成為公司和客戶不必要的負擔。一旦塵埃落定，危機解決，就可以開始研究問題發生的根本原因了。

　　持續交付的目標，不是要讓修正補丁更易于處理，而是要制定出編碼和測試的標準，消除對修正補丁的需要。每次流程失敗的時候，就是你學習如何改進代碼標準和測試實踐的機會，避免重大bug再次發生。同樣地，這也能為你提供理由，檢查日程表制定方針中的缺陷，看看是什么導致流程的停滯和問題。如果無法同時在這兩方面聚焦，你就永遠不能保證所有的bug修復都可以通過嚴格控制的流程。

　　簡而言之，持續改進是任何形式的持續交付的根本組件。

　　關于作者

　　Jonathan Allen從2006年開始就為InfoQ撰寫新聞報道，目前是.NET領域的首席編輯。如果您希望為InfoQ編寫新聞或是有價值的文章，請通過jonathan@infoq.com聯系他。

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