目前IT行業(yè)中，似乎“要不要做持續(xù)集成？”已經(jīng)不再是討論的焦點，取而代之的是“如何進(jìn)行持續(xù)集成？”。在前一篇文章中，我介紹了Cruise團(tuán)隊持續(xù)集成的演進(jìn)過程。在最后，還曾提及Cruise團(tuán)隊的持續(xù)部署。本文將結(jié)合團(tuán)隊的實際情況，與大家分享持續(xù)部署的實踐心得。

　　“最后一哩”問題

　　持續(xù)集成解決了軟件開發(fā)中的部分問題，但還有更為重要的一部分有待解決，即“通過什么樣的方法，可以讓軟件盡快地在真正的生產(chǎn)環(huán)境下運行，從而實現(xiàn)軟件的價值”。在軟件開發(fā)過程中，“從功能開發(fā)完成開始直到將其部署至生產(chǎn)環(huán)境中正式運行”這一階段被稱為“最后一哩”。如果從一開始就對產(chǎn)品發(fā)布足夠重視的話，那么這“最后一哩”可能只需要幾分鐘，甚至幾秒鐘就完成了。然而，事實上大多數(shù)項目在這一階段會花上幾個星期，更有甚者可能會是幾個月。

　　為什么會這樣呢？對于復(fù)雜軟件來說，無論什么環(huán)境中的部署（測試環(huán)境，試運行環(huán)境，還是生產(chǎn)）都很困難。當(dāng)軟件第一次被部署到非開發(fā)環(huán)境去測試，或者當(dāng)軟件功能及其環(huán)境有較大變化時，通常都會暴露出很多問題。而在做用戶驗收測試時，常常會發(fā)現(xiàn)更多的問題，例如不能滿足非功能需求，用戶操作不方便，功能與用 戶真正需要的東西相差太遠(yuǎn)等等。而開發(fā)團(tuán)隊只有修復(fù)這些缺陷后，才能再次部署測試。于是，這個過程會不斷反復(fù)，直至該軟件足夠穩(wěn)定，才可以部署到生產(chǎn)環(huán)境中。

　　即然部署到測試環(huán)境都這么困難，那么在生產(chǎn)環(huán)境中部署的風(fēng)險豈不會更大嗎？而且，更為嚴(yán)重的是：當(dāng)生產(chǎn)環(huán)境部署出現(xiàn)問題時，擺在你面前的選擇就所剩無幾啦（通常是回滾到以前的狀態(tài)，而“回滾”這段時間的停機(jī)成本是相當(dāng)高的）。

　　上述原因就會導(dǎo)致大多數(shù)組織對產(chǎn)品的發(fā)布采用“保守策略”，即降低軟件的發(fā)布頻率，這也導(dǎo)致兩次發(fā)布之間的版本特性差異相對較大。這樣一來，發(fā)布風(fēng)險并未因發(fā)布間隔時間加長而降低，反而更高了。當(dāng)各方面的因素結(jié)合在一起時，軟件發(fā)布這一環(huán)節(jié)就變得昂貴而又緩慢啦。而通常“發(fā)布過程與頻率”決定了產(chǎn)品在市場中的位置。

　　那么，如何更好地解決“最后一哩”這一問題呢？實現(xiàn)持續(xù)部署！ 即將持續(xù)集成實踐擴(kuò)展到整個軟件生命周期頻繁且規(guī)律性地自動構(gòu)建代碼并將其部署到測試環(huán)境中，然后通過一系列的測試，選擇適當(dāng)?shù)陌姹静渴鸬筋A(yù)演環(huán)境中試運行，最后選擇穩(wěn)定的版本部署到生產(chǎn)環(huán)境中，從而使開發(fā)團(tuán)隊盡早從最終客戶那里得到反饋，而最終客戶盡早得到軟件的價值。

　　“持續(xù)部署”源于部署時的痛苦

　　在使用Cruise來構(gòu)建Cruise本身以后的第二周后，當(dāng)我們想再次升級它時，因沒有事先考慮好升級方式，結(jié)果用了兩人天才把它搞定。從那以后，我們就開始了Cruise的持續(xù)部署之旅。

　　持續(xù)部署環(huán)境

　　目前Cruise的研發(fā)環(huán)境中，有一個被稱為“UAT（User Acceptance Testing）”的測試環(huán)境，目前它由一臺Cruise Server和近20臺Agent組成，用于Cruise團(tuán)隊自身的持續(xù)集成與部署管理。還有另一個被稱為“Production”的預(yù)發(fā)布生產(chǎn)環(huán)境，它由一臺Cruise Server和近70臺Agent組成，由多個項目組同時使用。“Production”環(huán)境是真實的生產(chǎn)環(huán)境，部署失敗，就意味著損失。因此，雖然部署工作可以通過自動化腳本完成，但我們還是在“UAT”和“Production”兩個Stage之前加上了人工開關(guān)（manual approval），如下圖所示。前三個Stage全部是自動觸發(fā)，其后全部為手工觸發(fā)。每個待發(fā)布的版本都會先被部署到UAT環(huán)境中，實際上也就做了試 運行，如果該版本穩(wěn)定，則部署到“Production”環(huán)境中。這樣就使部署風(fēng)險盡在掌控之中。

　　讓持續(xù)部署成功的要點

　　1. 充分而廣泛的自動化測試覆蓋

　　目前我們的測試包括單元測試、End2End測試、功能測試和性能測試。其中單元測試、End2End測試及功能測試都在同一個Pipeline中，每次代碼提交都會運行這些測試。而性能測試在另一個Pipeline中，用于每次部署后，收集UAT環(huán)境和Production環(huán)境的性能指標(biāo)。由于部署頻率足夠，我們可以掌握性能數(shù)據(jù)的微小變化，據(jù)此來采取相應(yīng)的優(yōu)化措施。

　　寫單元測試已經(jīng)成為不爭的事實，自不必說。另外，由于Cruise與很多版本管理軟件打交道，這里所說的End2End測試是指與這些外部接口的測試。而功能測試是指將Cruise Server和Agent真正在測試機(jī)器上運行起來后，再運行TWIST自動化測試套件。我們對功能測試的原則就是每個Story都要有功能測試覆蓋，QA與開發(fā)人員共用編寫功能測試用例，由開發(fā)人員實現(xiàn)之，而且功能測試要讓真實的Cruise Server和Agent進(jìn)行通信的基礎(chǔ)上進(jìn)行。TWIST是我們公司的另一款產(chǎn)品，用于自動化功能測試，其測試編輯界面如下所示：

　　2. 盡可能短的測試反饋時間

　　盡管測試數(shù)量較大，測試的絕對運行時間較長，但結(jié)合Cruise本身提供的并行運行特性，團(tuán)隊成員胡凱，Derek和李彥輝自行開發(fā)的測試負(fù)載均衡工具（Test-load-balancer）將所有測試分成若干份，Cruise將其分配到Agent集群中同時運行，使單元測試或其它測試在可接受的相對時間內(nèi)完成（單元測試在15分鐘之內(nèi)，功能測試在30分鐘之內(nèi)）。近期還將增加數(shù)個Agent，以便繼續(xù)縮短測試需要的時間。

　　3. 部署過程自動化

　　當(dāng)部署復(fù)雜軟件時，都會使用人工過程，而且可能會花上幾天的時間。而這種部署過程通常比較復(fù)雜，而且很難可靠地重復(fù)操作。因此，人們會寫一些文檔幫助這一過程，但文檔常常更新不及時。有時，還需要幾個關(guān)鍵性人物同時在場才能完成。

　　當(dāng)每次由不同的人員進(jìn)行部署操作時，出錯的概率就增加，所以要盡可能少的人工步驟。

　　在Cruise的Pipeline中，盡管由人來觸發(fā)兩個環(huán)境中的部署，但部署過程本身是自動化的。在部署過程中，Cruise的安裝包會自動關(guān)閉服務(wù)器，更新自身程序和升級數(shù)據(jù)庫，然后再重新啟動。所有的Agent也會以Server為準(zhǔn)，自動更新到與其相同的版本，而不必人工去升級每個 Agent（每次為70個Agent的手動升級也是很大的成本，所以我們做了自動升級這個特性）。

　　4. 部署過程要保證數(shù)據(jù)安全

　　如果因為持續(xù)部署而導(dǎo)致數(shù)據(jù)丟失或錯誤，會得不償失。所以，我們每次修改數(shù)據(jù)庫結(jié)構(gòu)或配置文件的結(jié)構(gòu)后，都會寫出相應(yīng)的遷移腳本，并在部署過程中運行。

　　目前我們使用由Thoughtworkers開發(fā)的開源項目DBDeploy來做數(shù)據(jù)庫升級。對于XML配置文件的修改，我們也自行開發(fā)了一個遷移框架。

　　5. 在穩(wěn)定的前提下，盡早部署

　　有人會問：“為什么要持續(xù)部署?你又如何知道部署的版本是否穩(wěn)定呢？宕機(jī)了怎么辦？”的確，沒有哪個開發(fā)人員希望持續(xù)集成服務(wù)器在工作時間內(nèi)宕機(jī)。盡管我們無法百分之百確保每個部署版本都穩(wěn)定，但在可預(yù)見的范圍內(nèi)穩(wěn)定就可以了，否則我們就無法解決“最后一哩”問題。

　　Cruise在最初三個迭代（迭代時間為一個星期）后，就開始用Cruise來做自己的持續(xù)集成服務(wù)器了（即UAT環(huán)境）。我們讓它在UAT環(huán)境上 運行了兩周，沒有發(fā)現(xiàn)什么問題，說明版本相對穩(wěn)定，就將它部署到“Production”環(huán)境上了。在那以后，隨著用戶的增多，很多人認(rèn)為由于部署失敗而 導(dǎo)致持續(xù)集成服務(wù)器宕機(jī)的風(fēng)險要高于那些新特性和修復(fù)的缺陷。因此，我們的客戶要求新版本部署至 “Production”環(huán)境之前，一定要在UAT環(huán)境上運行。目前，Cruise部署到UAT環(huán)境的頻率不固定（一般為兩天至一周），而部署到 Production環(huán)境的頻率為一周。也就是說，Production環(huán)境上的版本要落后于UAT一周的時間。

　　6. 完善的風(fēng)險緩解措施

　　隨著項目的進(jìn)行，難免會有部署失敗的情況，所以一定要有風(fēng)險緩解措施。例如：

　　(1) 部署盡可能在用戶少的時候；(2) 部署時必須有技術(shù)人員在場；(2) 每次部署前備份原始數(shù)據(jù)；(3) 時刻準(zhǔn)備回滾腳本。

　　7. 將同樣的產(chǎn)物部署到不同的環(huán)境中

　　讓你的產(chǎn)品可以部署到不同的環(huán)境中，如果這些環(huán)境的環(huán)境配置不同，則把有關(guān)環(huán)境配置的內(nèi)容排除在你的產(chǎn)品之外。如果你有很多個配置變量，請讓這些配置保存在同一處，而且有默認(rèn)值。

　　基于這一原則，Cruise唯一的配置就是XML文件。

　　8. 不斷的反思與重構(gòu)

　　這一點就沒有什么可說的了。它適用于所有的活動。

　　小結(jié)

　　實踐表明，建立自動化部署管道的益處很多。在過去的幾年中，ThoughtWorks利用這一方法幫助很多項目組和公司解決了他們的“最后一哩”問題。例如，在某項目中，通過自動化部署過程，使部署頻率從幾天一次提高到每天一次，而且該過程耗時少于15中分鐘（其僅有一分鐘的停機(jī)時間）。這對軟件整個生命周期的交付階段有著積極作用，只要按下鼠標(biāo)就可以準(zhǔn)備好所需要測試環(huán)境，從而減少了人為失誤造成的不必要的損失，顯著降低軟件發(fā)布的風(fēng)險。另外，頻繁且輕松的發(fā)布讓開發(fā)人員全神貫注于他們想做的事情：開發(fā)新的功能。

it知識庫：走向“持續(xù)部署”，轉(zhuǎn)載需保留來源！

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