❝
原文: http://timothyfitz.com/2009/02/08/continuous-deployment/
❞
Alex 已經重構了一些網站後端的代碼。當提交這個小任務的代碼後，Alex 繼續開發下一個特性。
當代碼部署到生產環境兩週以後，這段代碼讓整個網站宕機。自動化測試沒有測試到一個字符導致的拼寫錯誤，連鎖故障讓人想起了 Twitter 剛剛發佈的時候。人們花了8個小時隔離問題，修復了這個錯誤的字符，並部署到生產環境，終於回覆正常。
Alex 詛咒運氣，指責人類的無懈可擊，以及軟件工程不可避免的成本，然後繼續下一個任務。
這個故事每天都在我所知道的創業公司發生。這很糟糕。Alex 有一個她不知道的問題。她的軟件開發實踐是不可持續的。像這樣“愚蠢的失誤”會隨着產品增長的越來越複雜、團隊越來越大而變得更加頻繁。Alex 需要切換到一個可以規模化的解決方案。
在我的到這個解決方案前，讓我先告訴你一些常見的解決方案。當這些解決方案產生了真實的問題後，它們就不是能解決 Alex 境遇的解決方案。
「更多的手動測試」：這個明顯不可能隨着複雜性的提升而規模化。這麼做也無法逐字的捕獲每個問題，因爲你的測試沙箱或者測試集羣永遠無法做到和生產環境一模一樣。
「更多前置的計劃」：前置計劃就像烹飪菜譜中的條目。它無法準確的告訴你多少是多，多少是少。但是我將要告訴你要剛剛好——不要太多也不要太少，因爲那些無疑會毀掉了食物或這產品。過度計劃的自然趨勢是專注於非現實問題。 現在你會犯更多愚蠢的錯誤，但它們將是針對那些無關緊要的需求設計的。
「多的自動化測試」：自動化測試很棒，更多的自動化測試更好。但無論多少自動化測試都無法確保在人類的天性下某個功能完全正常，因爲沒有任何自動化測試會像用戶那樣殘酷、隨機、惡意、無知或激進。
「代碼審查和結對編程是優秀的實踐」：這些實踐將提升代碼質量，防止缺陷並培養你的程序員。雖然這些實踐可以在很大程度上減少缺陷，但最終他們受到以下事實的限制：雖然兩個人比一個人好，但他們仍然是人。 這些實踐只能捕獲到你的組織作爲一個整體已經有能力能夠發現的故障。
「降低發佈頻率」：雖然這麼做可以降低宕機時間（軟件中斷並回滾），但開發和返工時間會更大，失誤仍然會繼續出現。其自然的趨勢會導致發佈更加不頻繁，直到你完全不發佈。然後你會被強迫做一次完全的重寫，這依然是末日。
那麼 Alex 應該怎麼辦呢？ 持續部署！讓每一次代碼提交應當立即部署到生產環境。讓我們重新看看 Alex 的故事，假設她已經可以使用理想的持續部署實踐。Alex 提交代碼。幾分鐘後她集羣健康狀態異常。故障很容易追溯到並會滾 Alex 的變更。Alex 花了最少的時間調試，找到它的拼寫錯誤很容易。她的變更仍然導致了級聯的故障，但是宕機時間已經最小了。
這是經典的「快速失敗模式」在軟件發佈過程中的一個實現。你和引入故障變更越近，你就能獲得更多的數據修復這個故障。在代碼中快速失敗意味着在輸入無效的時候拋出一個異常而不是等待它在以後未知的地方出錯。在一個軟件發佈的過程中快速失敗意味着儘快發佈未部署的代碼，而不是等待一週後出現發佈故障。
持續部署是簡單的：只需要越來越頻繁的發佈你的代碼。也許從今天開始替代每週或者每月的發佈頻率，但是隨着時間的推移，你會達到理想的目標並且在過程中持續獲得收益。
2009年2月8日
Timothy Fitz
（完）