JJim Bird指出，人們?cè)谡劦匠掷m(xù)部署時(shí)，說得最多的是一些瑣碎的修改，例如小的調(diào)整、表面改動(dòng)或小缺陷的修復(fù)。任何大于這些的修改都需要遵循相應(yīng)細(xì)致、嚴(yán)謹(jǐn)?shù)姆椒ā?/p>

　　Jim認(rèn)為，

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

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

但是一旦部署到生產(chǎn)環(huán)境，就會(huì)影響用戶和實(shí)際數(shù)據(jù)，回滾將很昂貴，因?yàn)槟憧赡鼙仨殻?ul>

將數(shù)據(jù)庫回滾到之前的模式和規(guī)范。

考慮當(dāng)前正在使用你站點(diǎn)的用戶所受的影響，以及如何在他們的眼皮子底下修改應(yīng)用程序（可能會(huì)導(dǎo)致鏈接中斷，Ajax請(qǐng)求失敗）。

如果出了問題（回滾不是你想進(jìn)行就能進(jìn)行的），你甚至可能不得不發(fā)郵件知會(huì)所有受影響的用戶，或者處理各種支持請(qǐng)求。

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

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

　　那么，一個(gè)團(tuán)隊(duì)如何確保他們認(rèn)識(shí)到持續(xù)部署的價(jià)值呢？

　　Eric建議如下：

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

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

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

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

　　Jim總結(jié)了一下，

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

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

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

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