|
目前IT行業(yè)中,似乎“要不要做持續(xù)集成?”已經(jīng)不再是討論的焦點(diǎn),取而代之的是“如何進(jìn)行持續(xù)集成?”。在前一篇文章中,我介紹了Cruise團(tuán)隊(duì)持續(xù)集成的演進(jìn)過程。在最后,還曾提及Cruise團(tuán)隊(duì)的持續(xù)部署。本文將結(jié)合團(tuán)隊(duì)的實(shí)際情況,與大家分享持續(xù)部署的實(shí)踐心得。
“最后一哩”問題
持續(xù)集成解決了軟件開發(fā)中的部分問題,但還有更為重要的一部分有待解決,即“通過什么樣的方法,可以讓軟件盡快地在真正的生產(chǎn)環(huán)境下運(yùn)行,從而實(shí)現(xiàn)軟件的價(jià)值”。在軟件開發(fā)過程中,“從功能開發(fā)完成開始直到將其部署至生產(chǎn)環(huán)境中正式運(yùn)行”這一階段被稱為“最后一哩”。如果從一開始就對(duì)產(chǎn)品發(fā)布足夠重視的話,那么這“最后一哩”可能只需要幾分鐘,甚至幾秒鐘就完成了。然而,事實(shí)上大多數(shù)項(xiàng)目在這一階段會(huì)花上幾個(gè)星期,更有甚者可能會(huì)是幾個(gè)月。
為什么會(huì)這樣呢?對(duì)于復(fù)雜軟件來說,無論什么環(huán)境中的部署(測(cè)試環(huán)境,試運(yùn)行環(huán)境,還是生產(chǎn))都很困難。當(dāng)軟件第一次被部署到非開發(fā)環(huán)境去測(cè)試,或者當(dāng)軟件功能及其環(huán)境有較大變化時(shí),通常都會(huì)暴露出很多問題。而在做用戶驗(yàn)收測(cè)試時(shí),常常會(huì)發(fā)現(xiàn)更多的問題,例如不能滿足非功能需求,用戶操作不方便,功能與用 戶真正需要的東西相差太遠(yuǎn)等等。而開發(fā)團(tuán)隊(duì)只有修復(fù)這些缺陷后,才能再次部署測(cè)試。于是,這個(gè)過程會(huì)不斷反復(fù),直至該軟件足夠穩(wěn)定,才可以部署到生產(chǎn)環(huán)境中。
即然部署到測(cè)試環(huán)境都這么困難,那么在生產(chǎn)環(huán)境中部署的風(fēng)險(xiǎn)豈不會(huì)更大嗎?而且,更為嚴(yán)重的是:當(dāng)生產(chǎn)環(huán)境部署出現(xiàn)問題時(shí),擺在你面前的選擇就所剩無幾啦(通常是回滾到以前的狀態(tài),而“回滾”這段時(shí)間的停機(jī)成本是相當(dāng)高的)。
上述原因就會(huì)導(dǎo)致大多數(shù)組織對(duì)產(chǎn)品的發(fā)布采用“保守策略”,即降低軟件的發(fā)布頻率,這也導(dǎo)致兩次發(fā)布之間的版本特性差異相對(duì)較大。這樣一來,發(fā)布風(fēng)險(xiǎn)并未因發(fā)布間隔時(shí)間加長而降低,反而更高了。當(dāng)各方面的因素結(jié)合在一起時(shí),軟件發(fā)布這一環(huán)節(jié)就變得昂貴而又緩慢啦。而通常“發(fā)布過程與頻率”決定了產(chǎn)品在市場(chǎng)中的位置。
那么,如何更好地解決“最后一哩”這一問題呢?實(shí)現(xiàn)持續(xù)部署! 即將持續(xù)集成實(shí)踐擴(kuò)展到整個(gè)軟件生命周期頻繁且規(guī)律性地自動(dòng)構(gòu)建代碼并將其部署到測(cè)試環(huán)境中,然后通過一系列的測(cè)試,選擇適當(dāng)?shù)陌姹静渴鸬筋A(yù)演環(huán)境中試運(yùn)行,最后選擇穩(wěn)定的版本部署到生產(chǎn)環(huán)境中,從而使開發(fā)團(tuán)隊(duì)盡早從最終客戶那里得到反饋,而最終客戶盡早得到軟件的價(jià)值。
“持續(xù)部署”源于部署時(shí)的痛苦
在使用Cruise來構(gòu)建Cruise本身以后的第二周后,當(dāng)我們想再次升級(jí)它時(shí),因沒有事先考慮好升級(jí)方式,結(jié)果用了兩人天才把它搞定。從那以后,我們就開始了Cruise的持續(xù)部署之旅。
持續(xù)部署環(huán)境
目前Cruise的研發(fā)環(huán)境中,有一個(gè)被稱為“UAT(User Acceptance Testing)”的測(cè)試環(huán)境,目前它由一臺(tái)Cruise Server和近20臺(tái)Agent組成,用于Cruise團(tuán)隊(duì)自身的持續(xù)集成與部署管理。還有另一個(gè)被稱為“Production”的預(yù)發(fā)布生產(chǎn)環(huán)境,它由一臺(tái)Cruise Server和近70臺(tái)Agent組成,由多個(gè)項(xiàng)目組同時(shí)使用。“Production”環(huán)境是真實(shí)的生產(chǎn)環(huán)境,部署失敗,就意味著損失。因此,雖然部署工作可以通過自動(dòng)化腳本完成,但我們還是在“UAT”和“Production”兩個(gè)Stage之前加上了人工開關(guān)(manual approval),如下圖所示。前三個(gè)Stage全部是自動(dòng)觸發(fā),其后全部為手工觸發(fā)。每個(gè)待發(fā)布的版本都會(huì)先被部署到UAT環(huán)境中,實(shí)際上也就做了試 運(yùn)行,如果該版本穩(wěn)定,則部署到“Production”環(huán)境中。這樣就使部署風(fēng)險(xiǎn)盡在掌控之中。
讓持續(xù)部署成功的要點(diǎn)
1. 充分而廣泛的自動(dòng)化測(cè)試覆蓋
目前我們的測(cè)試包括單元測(cè)試、End2End測(cè)試、功能測(cè)試和性能測(cè)試。其中單元測(cè)試、End2End測(cè)試及功能測(cè)試都在同一個(gè)Pipeline中,每次代碼提交都會(huì)運(yùn)行這些測(cè)試。而性能測(cè)試在另一個(gè)Pipeline中,用于每次部署后,收集UAT環(huán)境和Production環(huán)境的性能指標(biāo)。由于部署頻率足夠,我們可以掌握性能數(shù)據(jù)的微小變化,據(jù)此來采取相應(yīng)的優(yōu)化措施。
寫單元測(cè)試已經(jīng)成為不爭的事實(shí),自不必說。另外,由于Cruise與很多版本管理軟件打交道,這里所說的End2End測(cè)試是指與這些外部接口的測(cè)試。而功能測(cè)試是指將Cruise Server和Agent真正在測(cè)試機(jī)器上運(yùn)行起來后,再運(yùn)行TWIST自動(dòng)化測(cè)試套件。我們對(duì)功能測(cè)試的原則就是每個(gè)Story都要有功能測(cè)試覆蓋,QA與開發(fā)人員共用編寫功能測(cè)試用例,由開發(fā)人員實(shí)現(xiàn)之,而且功能測(cè)試要讓真實(shí)的Cruise Server和Agent進(jìn)行通信的基礎(chǔ)上進(jìn)行。TWIST是我們公司的另一款產(chǎn)品,用于自動(dòng)化功能測(cè)試,其測(cè)試編輯界面如下所示:
2. 盡可能短的測(cè)試反饋時(shí)間
盡管測(cè)試數(shù)量較大,測(cè)試的絕對(duì)運(yùn)行時(shí)間較長,但結(jié)合Cruise本身提供的并行運(yùn)行特性,團(tuán)隊(duì)成員胡凱,Derek和李彥輝自行開發(fā)的測(cè)試負(fù)載均衡工具(Test-load-balancer)將所有測(cè)試分成若干份,Cruise將其分配到Agent集群中同時(shí)運(yùn)行,使單元測(cè)試或其它測(cè)試在可接受的相對(duì)時(shí)間內(nèi)完成(單元測(cè)試在15分鐘之內(nèi),功能測(cè)試在30分鐘之內(nèi))。近期還將增加數(shù)個(gè)Agent,以便繼續(xù)縮短測(cè)試需要的時(shí)間。
3. 部署過程自動(dòng)化
當(dāng)部署復(fù)雜軟件時(shí),都會(huì)使用人工過程,而且可能會(huì)花上幾天的時(shí)間。而這種部署過程通常比較復(fù)雜,而且很難可靠地重復(fù)操作。因此,人們會(huì)寫一些文檔幫助這一過程,但文檔常常更新不及時(shí)。有時(shí),還需要幾個(gè)關(guān)鍵性人物同時(shí)在場(chǎng)才能完成。
當(dāng)每次由不同的人員進(jìn)行部署操作時(shí),出錯(cuò)的概率就增加,所以要盡可能少的人工步驟。
在Cruise的Pipeline中,盡管由人來觸發(fā)兩個(gè)環(huán)境中的部署,但部署過程本身是自動(dòng)化的。在部署過程中,Cruise的安裝包會(huì)自動(dòng)關(guān)閉服務(wù)器,更新自身程序和升級(jí)數(shù)據(jù)庫,然后再重新啟動(dòng)。所有的Agent也會(huì)以Server為準(zhǔn),自動(dòng)更新到與其相同的版本,而不必人工去升級(jí)每個(gè) Agent(每次為70個(gè)Agent的手動(dòng)升級(jí)也是很大的成本,所以我們做了自動(dòng)升級(jí)這個(gè)特性)。
4. 部署過程要保證數(shù)據(jù)安全
如果因?yàn)槌掷m(xù)部署而導(dǎo)致數(shù)據(jù)丟失或錯(cuò)誤,會(huì)得不償失。所以,我們每次修改數(shù)據(jù)庫結(jié)構(gòu)或配置文件的結(jié)構(gòu)后,都會(huì)寫出相應(yīng)的遷移腳本,并在部署過程中運(yùn)行。
目前我們使用由Thoughtworkers開發(fā)的開源項(xiàng)目DBDeploy來做數(shù)據(jù)庫升級(jí)。對(duì)于XML配置文件的修改,我們也自行開發(fā)了一個(gè)遷移框架。
5. 在穩(wěn)定的前提下,盡早部署
有人會(huì)問:“為什么要持續(xù)部署?你又如何知道部署的版本是否穩(wěn)定呢?宕機(jī)了怎么辦?”的確,沒有哪個(gè)開發(fā)人員希望持續(xù)集成服務(wù)器在工作時(shí)間內(nèi)宕機(jī)。盡管我們無法百分之百確保每個(gè)部署版本都穩(wěn)定,但在可預(yù)見的范圍內(nèi)穩(wěn)定就可以了,否則我們就無法解決“最后一哩”問題。
Cruise在最初三個(gè)迭代(迭代時(shí)間為一個(gè)星期)后,就開始用Cruise來做自己的持續(xù)集成服務(wù)器了(即UAT環(huán)境)。我們讓它在UAT環(huán)境上 運(yùn)行了兩周,沒有發(fā)現(xiàn)什么問題,說明版本相對(duì)穩(wěn)定,就將它部署到“Production”環(huán)境上了。在那以后,隨著用戶的增多,很多人認(rèn)為由于部署失敗而 導(dǎo)致持續(xù)集成服務(wù)器宕機(jī)的風(fēng)險(xiǎn)要高于那些新特性和修復(fù)的缺陷。因此,我們的客戶要求新版本部署至 “Production”環(huán)境之前,一定要在UAT環(huán)境上運(yùn)行。目前,Cruise部署到UAT環(huán)境的頻率不固定(一般為兩天至一周),而部署到 Production環(huán)境的頻率為一周。也就是說,Production環(huán)境上的版本要落后于UAT一周的時(shí)間。
6. 完善的風(fēng)險(xiǎn)緩解措施
隨著項(xiàng)目的進(jìn)行,難免會(huì)有部署失敗的情況,所以一定要有風(fēng)險(xiǎn)緩解措施。例如:
(1) 部署盡可能在用戶少的時(shí)候;(2) 部署時(shí)必須有技術(shù)人員在場(chǎng);(2) 每次部署前備份原始數(shù)據(jù);(3) 時(shí)刻準(zhǔn)備回滾腳本。
7. 將同樣的產(chǎn)物部署到不同的環(huán)境中
讓你的產(chǎn)品可以部署到不同的環(huán)境中,如果這些環(huán)境的環(huán)境配置不同,則把有關(guān)環(huán)境配置的內(nèi)容排除在你的產(chǎn)品之外。如果你有很多個(gè)配置變量,請(qǐng)讓這些配置保存在同一處,而且有默認(rèn)值。
基于這一原則,Cruise唯一的配置就是XML文件。
8. 不斷的反思與重構(gòu)
這一點(diǎn)就沒有什么可說的了。它適用于所有的活動(dòng)。
小結(jié)
實(shí)踐表明,建立自動(dòng)化部署管道的益處很多。在過去的幾年中,ThoughtWorks利用這一方法幫助很多項(xiàng)目組和公司解決了他們的“最后一哩”問題。例如,在某項(xiàng)目中,通過自動(dòng)化部署過程,使部署頻率從幾天一次提高到每天一次,而且該過程耗時(shí)少于15中分鐘(其僅有一分鐘的停機(jī)時(shí)間)。這對(duì)軟件整個(gè)生命周期的交付階段有著積極作用,只要按下鼠標(biāo)就可以準(zhǔn)備好所需要測(cè)試環(huán)境,從而減少了人為失誤造成的不必要的損失,顯著降低軟件發(fā)布的風(fēng)險(xiǎn)。另外,頻繁且輕松的發(fā)布讓開發(fā)人員全神貫注于他們想做的事情:開發(fā)新的功能。
it知識(shí)庫:走向“持續(xù)部署”,轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除,多謝。