持續集成實踐之持續交付的五個核心實踐(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.anti-gravitydesign.com