JJim Bird指出，人們在談到持續部署時，說得最多的是一些瑣碎的修改，例如小的調整、表面改動或小缺陷的修復。任何大于這些的修改都需要遵循相應細致、嚴謹的方法。

　　Jim認為，

數據庫模式（Schema）不能一直在變。較大的功能不能、也不應該一直改變，即使是在進行摸黑啟動（dark launching）。以Etsy的做法為例（Etsy是典型的應用持續部署的公司），它不會持續部署一些較大的公共模塊。和任何聰明的公司一樣，他們會與運維、客服及產品管理部門一起花時間做規劃、設計、原型、測試、評審，并最終部署。

　　Jo Liss提出，持續部署的真正挑戰是回滾修改的代價。Jo認為，限制持續集成的頻率的因素更多是技術上的，但對于回滾修改成本巨大的持續部署而言，它的限制則完全不同。

但是一旦部署到生產環境，就會影響用戶和實際數據，回滾將很昂貴，因為你可能必須：

• 將數據庫回滾到之前的模式和規范。
• 考慮當前正在使用你站點的用戶所受的影響，以及如何在他們的眼皮子底下修改應用程序（可能會導致鏈接中斷，Ajax請求失敗）。
• 如果出了問題（回滾不是你想進行就能進行的），你甚至可能不得不發郵件知會所有受影響的用戶，或者處理各種支持請求。

　　同樣地，Eric Ries認為持續部署的最大挑戰是必須時刻準備交付。

一方面，這是對客戶響應的終極目標。另一方面，這簡直是不可能完成的任務。階段性交付給我們編織了一張（有些虛幻的）安全網。和其他人（測試團隊）分擔測試責任也讓人神清氣爽。

　　那么，一個團隊如何確保他們認識到持續部署的價值呢？

　　Eric建議如下：

• 不要強推功能，而是根據客戶反饋信號做部署
• 分批小規模修改代碼
• 相對于單元測試，更傾向于盡可能多的進行功能測試
• 在系統和應用程序層都實現警告（alerts）和監控功能
• 只容忍意外錯誤發生一次，并立即修復

　　Jo認為大家應該減少提交代碼到服務器的次數。他指出，正常的部署延遲是在完成代碼后的5小時到2天之間。

那么如果你能靜下心來，而不是向誘惑屈服，剛愎自用地立即部署，那么你可能可以避免大部分令人追悔莫及的修改，這些錯誤的修改大概占總數的5%，但真的一定是你不希望提交到產品服務器的。而你等待的這些時間，可能只是錯過了為數不多的早期的用戶反饋。

　　這一切并不是說持續部署不可能實現。很多公司，比如Etsy、Heyo、IMVU和Atlassian都在做持續部署，而且很可能做得很不錯。

　　Jim總結了一下，

從持續部署確實可以學到很多，像如何使交付及部署更流暢、更簡單，如何降低風險，把工作分解得更小塊，然后再把它們串聯起來，設定節點監控、度量。但它不是或起碼不應該是“開發者的圣杯”。

　　查看英文原文：Continuous Deployment: Easier Said Than Done