持續部署：說(shuō)起來(lái)容易做起來(lái)難

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

　　Jim認為，

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

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

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

　　將數據庫回滾到之前的模式和規范。

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

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

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

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

　　那么，一個(gè)團隊如何確保他們認識到持續部署的價(jià)值呢?

　　Eric建議如下：

　　不要強推功能，而是根據客戶(hù)反饋信號做部署

　　分批小規模修改代碼

　　相對于單元測試，更傾向于盡可能多的進(jìn)行功能測試

　　在系統和應用程序層都實(shí)現警告(alerts)和監控功能

　　只容忍意外錯誤發(fā)生一次，并立即修復

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

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

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

　　Jim總結了一下，

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

原文轉自：http://kjueaiud.com