Etsy 每天部署程式碼數十次，因此沒有任何單次發布能拖垮網站

在 2000 年代，發布網站的新版本是一件大事：工程團隊把數週的變更打包成單次推送，為此安排停機時間，並把部署日視為一切可能同時出錯的時刻。Etsy 過去也是如此運作，由專責的部署團隊擔任守門人，每當打包發布出錯就得熬夜處理，因為沒有人能判斷究竟是數十項同時進行的變更中哪一項造成了失敗。

針對脆弱發布的標準解法，是在發布前增加更多流程——更長的 QA 週期、更多簽核、更大的預備環境——這只增加了延遲，卻沒有消除真正的風險：一次發布仍然同時送出四十項功能，因此單一錯誤仍迫使工程師在壓力下要麼全部復原，要麼在整批變更中翻找那條出錯的程式碼。

持續部署：每天數十次小型生產環境部署，每次都能輕易歸因且可還原，取代令人恐懼的發布之夜。

將每次部署的發布批次縮小到一項或少數幾項變更，使每次失敗都能輕易歸因且易於復原，而不是增加更多發布前流程。

大型打包發布會把任何單一錯誤淹沒在數十項變更之中，使歸因既慢又昂貴。

小批次意味著每次部署最多只有一個可能的原因，因此失敗能立即追溯。

小型變更各自可還原，因此不良部署可以撤銷，而不必回滾所有內容。

頻繁的小型部署將風險分散到許多低風險事件上，減少恐懼並鼓勵更小的批次。

當失敗難以診斷時，縮小批次規模，而不是在發布前增加更多流程。

到 2010 年中，Etsy 自家的工程主管報告每月約有 200 次生產環境部署且持續增加（「7 月有 204 次生產環境部署，比 6 月多約 30%」），每次規模都小到可追溯到單一工程師；到 2014 年，該公司公開引用的數字約為每天 30 次部署。