JJim Bird指出，人們在談到持續(xù)部署時，說得最多的是一些瑣碎的修改，例如小的調(diào)整、表面改動或小缺陷的修復。任何大于這些的修改都需要遵循相應細致、嚴謹?shù)姆椒ā?/p>

　　Jim認為，

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

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

但是一旦部署到生產(chǎn)環(huán)境，就會影響用戶和實際數(shù)據(jù)，回滾將很昂貴，因為你可能必須：

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

　　同樣地，Eric Ries認為持續(xù)部署的最大挑戰(zhàn)是必須時刻準備交付。

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

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

　　Eric建議如下：

• 不要強推功能，而是根據(jù)客戶反饋信號做部署
• 分批小規(guī)模修改代碼
• 相對于單元測試，更傾向于盡可能多的進行功能測試
• 在系統(tǒng)和應用程序?qū)佣紝崿F(xiàn)警告（alerts）和監(jiān)控功能
• 只容忍意外錯誤發(fā)生一次，并立即修復

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

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

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

　　Jim總結(jié)了一下，

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

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

it知識庫：持續(xù)部署：說起來容易做起來難，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。