張文林

摘要：敏捷軟件開(kāi)發(fā)方法已漸成主流，持續(xù)集成作為敏捷開(kāi)發(fā)的最佳實(shí)踐，近年來(lái)應(yīng)用廣泛。如何讓軟件從“開(kāi)發(fā)完成”迅速實(shí)現(xiàn)“交付使用”，解決“最后一公里問(wèn)題”，是不少企業(yè)孜孜以求的目標(biāo)。持續(xù)交付以持續(xù)集成作為基礎(chǔ)，使得頻繁且可靠交付成為常規(guī)活動(dòng)。結(jié)合G產(chǎn)品開(kāi)發(fā)過(guò)程，對(duì)持續(xù)交付進(jìn)行了詳述。

關(guān)鍵詞：敏捷開(kāi)發(fā)；持續(xù)集成（Continuous Integration， CI）；持續(xù)交付（Continuous Delivery， CD）；G產(chǎn)品；Jenkins環(huán)境

DOIDOI：10.11907/rjdk.171744

中圖分類(lèi)號(hào)：TP319文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：16727800（2017）010015903

0引言

隨著通訊技術(shù)的快速發(fā)展，用戶需求也愈來(lái)愈多樣化，隨之而來(lái)的是企業(yè)間競(jìng)爭(zhēng)的加劇。迅速、高效、高質(zhì)量的產(chǎn)品發(fā)布成為企業(yè)有力的競(jìng)爭(zhēng)法寶。通訊產(chǎn)品特有的高復(fù)雜性，對(duì)軟件的實(shí)時(shí)性、穩(wěn)定性、環(huán)境適應(yīng)性提出了更高要求。作為一種發(fā)布可靠軟件的系統(tǒng)方法，持續(xù)交付通過(guò)一系列的原則和技術(shù)實(shí)踐，解決了傳統(tǒng)軟件發(fā)布中普遍具有的周期長(zhǎng)、風(fēng)險(xiǎn)高等問(wèn)題[1]。

G產(chǎn)品是B公司針對(duì)市場(chǎng)推出的一款新一代產(chǎn)品，要求開(kāi)發(fā)周期短，且能夠按時(shí)高質(zhì)量完成交付。因?yàn)椤疤鎿Q競(jìng)爭(zhēng)對(duì)手產(chǎn)品”需求的特殊性，高效高質(zhì)量交付成為關(guān)鍵。B公司雖引入了敏捷開(kāi)發(fā)模式Scrum，在持續(xù)集成、快速迭代、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)等方面開(kāi)展了一些實(shí)踐，但從整個(gè)產(chǎn)品交付周期來(lái)看，仍存在開(kāi)發(fā)周期較長(zhǎng)、風(fēng)險(xiǎn)較高的問(wèn)題。因此，公司決定在現(xiàn)有敏捷開(kāi)發(fā)模式下引入持續(xù)交付的系統(tǒng)方法。

1持續(xù)交付系統(tǒng)方法

持續(xù)交付指軟件從版本控制庫(kù)到用戶手中這一過(guò)程的自動(dòng)化表現(xiàn)形式[4]。軟件的每次變更都會(huì)經(jīng)歷一個(gè)復(fù)雜的流程才能發(fā)布，包括軟件的構(gòu)建提交以及后續(xù)一系列不同階段的測(cè)試與版本管理，這些活動(dòng)通常需要多人或多個(gè)團(tuán)隊(duì)協(xié)作。持續(xù)交付描述的是從原始需求識(shí)別到最終產(chǎn)品部署過(guò)程中，以小批量的需求形式在各環(huán)節(jié)間順暢流動(dòng)，在短周期完成需求的小粒度頻繁交付，使軟件的反饋更及時(shí)。這種方式促進(jìn)了需求分析、產(chǎn)品的用戶體驗(yàn)以及交互設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、運(yùn)維等角色之間的密切協(xié)作。相比于傳統(tǒng)的瀑布式軟件開(kāi)發(fā)方法，效率明顯提高。

為實(shí)現(xiàn)持續(xù)交付，需遵循一系列軟件交付原則[4]：①為軟件發(fā)布創(chuàng)建一個(gè)可重復(fù)且可靠的過(guò)程；②盡力將所有事情自動(dòng)化；③將所有內(nèi)容都納入版本控制；④提前計(jì)劃；⑤內(nèi)建質(zhì)量；⑥“DONE”意味著“已發(fā)布”；⑦交付過(guò)程是每個(gè)成員的責(zé)任；⑧持續(xù)改進(jìn)。以上原則對(duì)應(yīng)持續(xù)交付系統(tǒng)方法的不同階段。

2持續(xù)交付階段

2.1提交階段

提交階段包括配置管理和代碼檢查兩個(gè)部分。

配置管理目的是保留每個(gè)文件的所有版本歷史信息，并使之易于查找；持續(xù)交付必須以全自動(dòng)化方式進(jìn)行，以全自動(dòng)化方式構(gòu)建、測(cè)試并部署軟件，源代碼、測(cè)試腳本、構(gòu)建與部署腳本等都必須納入版本管理[3]。

將所有事項(xiàng)都納入版本控制，意味著每個(gè)團(tuán)隊(duì)成員都使用相同的配置，團(tuán)隊(duì)成員發(fā)現(xiàn)問(wèn)題、提交問(wèn)題、討論問(wèn)題都在同一個(gè)語(yǔ)境中；同時(shí)，任意成員（不一定是團(tuán)隊(duì)成員）也可根據(jù)需要直接提取代碼，部署可運(yùn)行的軟件版本。

代碼檢查指開(kāi)發(fā)人員在編寫(xiě)完代碼后，將代碼提交到“源代碼庫(kù)”，從技術(shù)角度確認(rèn)整個(gè)系統(tǒng)是可以工作的。開(kāi)發(fā)人員一般做一些簡(jiǎn)單的編譯、代碼審查和單元測(cè)試工作。這些代碼檢查工作多為自動(dòng)化檢查。因?yàn)槭轻槍?duì)個(gè)人代碼的檢查，所以無(wú)法集成到整個(gè)開(kāi)發(fā)團(tuán)隊(duì)的CI環(huán)境中。

2.2自動(dòng)化驗(yàn)收測(cè)試階段

自動(dòng)化測(cè)試環(huán)境和腳本由開(kāi)發(fā)人員和測(cè)試人員合作創(chuàng)建。開(kāi)發(fā)人員和測(cè)試人員是相對(duì)的。敏捷團(tuán)隊(duì)可跨職能，團(tuán)隊(duì)里每個(gè)人都可以是測(cè)試人員[5]。自動(dòng)化驗(yàn)收測(cè)試階段一般要構(gòu)建和集成一個(gè)CI 環(huán)境，以保證代碼的編譯、單元測(cè)試、組裝打包、代碼分析（CppCheck、Coverity等）、冒煙測(cè)試、模擬環(huán)境測(cè)試等部分自動(dòng)化運(yùn)行并反饋結(jié)果。

盡可能自動(dòng)化是持續(xù)交付的前提條件。構(gòu)建過(guò)程自動(dòng)化使代碼頻繁提交成為可能；單元測(cè)試、集成測(cè)試、驗(yàn)收測(cè)試的自動(dòng)化，使持續(xù)集成成為可能；數(shù)據(jù)庫(kù)升級(jí)自動(dòng)化、網(wǎng)絡(luò)配置自動(dòng)化，使持續(xù)交付成為可能。

每個(gè)階段的自動(dòng)化測(cè)試運(yùn)行時(shí)間以及復(fù)雜性要適度。過(guò)長(zhǎng)或過(guò)于復(fù)雜的自動(dòng)化測(cè)試會(huì)影響執(zhí)行；自動(dòng)化測(cè)試時(shí)間太長(zhǎng)，會(huì)導(dǎo)致下一次自動(dòng)化測(cè)試包含多次提交，難以及時(shí)準(zhǔn)確發(fā)現(xiàn)問(wèn)題，同時(shí)，提交的效率也會(huì)降低，因?yàn)榇蠹視?huì)坐等上一次自動(dòng)化測(cè)試的完成。

2.3手工測(cè)試階段

手工測(cè)試階段主要用來(lái)發(fā)現(xiàn)自動(dòng)化測(cè)試沒(méi)有捕獲的缺陷，是自動(dòng)化測(cè)試的補(bǔ)充。手工測(cè)試一般在Sprint結(jié)束之后產(chǎn)品發(fā)布之前進(jìn)行，測(cè)試人員要反復(fù)做幾輪測(cè)試，以確保產(chǎn)品質(zhì)量[2]。手工測(cè)試通常包括探索性測(cè)試、性能測(cè)試以及用戶驗(yàn)收測(cè)試。

2.4發(fā)布階段

發(fā)布階段指在試運(yùn)行環(huán)境上進(jìn)行冒煙測(cè)試和集成測(cè)試。

發(fā)布階段不同測(cè)試反饋周期不同，運(yùn)行規(guī)律就不同。單元測(cè)試是代碼提交的基本測(cè)試，要求周期短、反饋快，一般要在半小時(shí)內(nèi)完成。自動(dòng)化驗(yàn)收測(cè)試又分為驗(yàn)收基本功能的冒煙測(cè)試和驗(yàn)證全部功能的集成測(cè)試，前者一般要求一兩個(gè)小時(shí)內(nèi)完成，后者一般要求當(dāng)天完成。

2.5度量

這里把度量單獨(dú)列出，是為了強(qiáng)調(diào)合理度量的重要性。度量存在于上述各階段中。從持續(xù)交付流程圖（見(jiàn)圖1）可以看出，所有的流程都是為了盡快得到反饋，以期提高質(zhì)量以及持續(xù)改進(jìn)。而改善反饋的最佳方法就是縮短反饋周期，并讓結(jié)果可視化。衡量持續(xù)交付軟件系統(tǒng)的能力指標(biāo)不是通過(guò)自動(dòng)化測(cè)試發(fā)現(xiàn)的缺陷數(shù)目，也不是團(tuán)隊(duì)成員代碼提交的速度，而是持續(xù)交付的反饋周期。提交代碼后自動(dòng)化測(cè)試周期有手工測(cè)試周期、發(fā)現(xiàn)缺陷周期、發(fā)現(xiàn)缺陷后解決問(wèn)題的周期。通過(guò)觀察持續(xù)交付流程中的各個(gè)階段，發(fā)現(xiàn)周期時(shí)間的關(guān)鍵路徑，找到辦法縮短它。endprint

3實(shí)踐與應(yīng)用

G產(chǎn)品由于需求的特殊性，交付速度成為產(chǎn)品成敗的關(guān)鍵，不能及時(shí)交付就意味著機(jī)會(huì)成本的增加。為快速交付高質(zhì)量的軟件產(chǎn)品，需要頻繁且自動(dòng)化地發(fā)布軟件?；谶@一目標(biāo)，G產(chǎn)品采取了以下步驟、方法。

3.1G產(chǎn)品配置管理

G產(chǎn)品配置管理工具采用Mercurial。Mercurial是一種輕量級(jí)分布式版本控制系統(tǒng)，采用 Python 語(yǔ)言實(shí)現(xiàn)，易于學(xué)習(xí)和使用，擴(kuò)展性強(qiáng)。

G產(chǎn)品與項(xiàng)目相關(guān)的所有內(nèi)容都提交到版本控制庫(kù)，包括產(chǎn)品代碼、測(cè)試代碼、構(gòu)建和測(cè)試腳本，以及相關(guān)第三方工具、軟件。

G產(chǎn)品每個(gè)版本保留的信息：①當(dāng)前版本號(hào)；②Baseline，也就是修改的上一個(gè)發(fā)布的版本號(hào)；③修改記錄。通過(guò)這些信息可以清楚地找出兩個(gè)版本之間的差別。

G產(chǎn)品代碼采取主干加分支的管理策略。分支的目的是幫助團(tuán)隊(duì)進(jìn)行并行開(kāi)發(fā)，即在同一時(shí)刻同時(shí)在兩個(gè)或多個(gè)工作流上開(kāi)發(fā)，且不會(huì)互相影響。每個(gè)分支的代碼合并到相應(yīng)主干時(shí)進(jìn)行一系列測(cè)試。合并和測(cè)試都是自動(dòng)化持續(xù)完成的。最后交付到release branch或者M(jìn)S（mainstream）上的代碼，就是可面向用戶發(fā)布的代碼（見(jiàn)圖2所示）。

圖2G產(chǎn)品分支策略

采用分支的另一個(gè)好處就是G產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)的每個(gè)成員都可頻繁提交代碼，不用擔(dān)心影響到其它功能或軟件版本。頻繁提交代碼優(yōu)點(diǎn)：①由于每次改動(dòng)都比較小，所以很少會(huì)構(gòu)建失敗。即使構(gòu)建或后期測(cè)試失敗，也很容易查找出問(wèn)題或回滾到上一個(gè)正確的版本上；②查找問(wèn)題或回滾的代價(jià)較小。

3.2G產(chǎn)品自動(dòng)化測(cè)試

G產(chǎn)品自動(dòng)化測(cè)試：①代碼靜態(tài)檢查，包括代碼構(gòu)建、Cppcheck、Coverity。代碼靜態(tài)檢查一般幾分鐘就可完成；②單元測(cè)試。這里的單元測(cè)試主要是系統(tǒng)級(jí)的，也就是集成了所有軟件模塊的單元測(cè)試。開(kāi)發(fā)人員在提交代碼前會(huì)單獨(dú)進(jìn)行模塊級(jí)的單元測(cè)試，模塊級(jí)的單元測(cè)試一般時(shí)間很短，易于執(zhí)行，可以是手工的，也可以是自動(dòng)化的。系統(tǒng)級(jí)的單元測(cè)試一般十幾分鐘就可完成；③冒煙測(cè)試。主要針對(duì)系統(tǒng)基本功能及已經(jīng)提交成功的部分新功能進(jìn)行測(cè)試。冒煙測(cè)試要求測(cè)試時(shí)間短、反饋速度快。G產(chǎn)品的冒煙測(cè)試一般會(huì)在一小時(shí)左右完成，每次構(gòu)建成功后會(huì)觸發(fā)運(yùn)行；④回歸測(cè)試?；貧w測(cè)試主要用來(lái)保證新的版本不會(huì)破壞原有版本功能。由于G產(chǎn)品的復(fù)雜性，其回歸測(cè)試的case比較多，測(cè)試周期也較長(zhǎng)，大概1 100多個(gè)case，需要運(yùn)行8個(gè)多小時(shí)，所以一般放在下班后執(zhí)行，晚上10點(diǎn)左右觸發(fā)，第二天早上就能看到結(jié)果。

反饋是所有軟件交付流程的核心。改善反饋的最佳方法是縮短反饋周期，并讓結(jié)果可視化[3]。G產(chǎn)品針對(duì)這兩點(diǎn)作了相應(yīng)處理。

為了縮短反饋周期，G產(chǎn)品不僅從自動(dòng)化測(cè)試用例上拆分為冒煙測(cè)試和回歸測(cè)試，在構(gòu)建上也進(jìn)行了拆分：①基本構(gòu)建只編譯新功能和盡可能少的原有功能，以保證在半小時(shí)內(nèi)反饋結(jié)果?；緲?gòu)建的觸發(fā)條件是有人提交代碼；②完整構(gòu)建，編譯所有功能時(shí)間較長(zhǎng)，一般要2～3個(gè)小時(shí)。完整構(gòu)建的觸發(fā)條件是每隔3小時(shí)觸發(fā)一次。

G產(chǎn)品結(jié)果可視化方法：①自動(dòng)化集成結(jié)果圖的可視化。通過(guò)顯示器顯示，團(tuán)隊(duì)成員抬頭就可看到當(dāng)前的執(zhí)行結(jié)果是紅色的（失敗）還是綠色的（成功）；②每個(gè)測(cè)試結(jié)果都會(huì)自動(dòng)發(fā)郵件到相關(guān)開(kāi)發(fā)人員郵箱，郵件標(biāo)題提示本次結(jié)果是失敗還是成功，郵件內(nèi)容包含當(dāng)前執(zhí)行的版本信息及改動(dòng)人信息。如果是失敗郵件，相應(yīng)人員可很快定位到哪個(gè)改動(dòng)影響了本次運(yùn)行。

3.3G產(chǎn)品手工測(cè)試

G產(chǎn)品自動(dòng)化測(cè)試全面，但由于產(chǎn)品的復(fù)雜性，需要在不同環(huán)境下作一些其它測(cè)試，如容量測(cè)試、探索性測(cè)試、易用性測(cè)試等，這些需要開(kāi)發(fā)人員手工完成。

G產(chǎn)品自動(dòng)化測(cè)試平臺(tái)可每天發(fā)布一個(gè)版本，手工測(cè)試人員不僅可每天得到一個(gè)確定可用的版本，還可查看每個(gè)版本的修改記錄，比如某個(gè)高優(yōu)先級(jí)的缺陷是否解決？某些新功能是否加進(jìn)來(lái)？從而選擇自己想要的版本。

G產(chǎn)品手工測(cè)試周期比較長(zhǎng)，一般需要一周時(shí)間。

3.4G產(chǎn)品版本發(fā)布

G產(chǎn)品版本發(fā)布要根據(jù)手工測(cè)試的結(jié)果確定，所以需要手工觸發(fā)自動(dòng)化發(fā)布流程。手工觸發(fā)指需要手工輸入版本號(hào)，然后一鍵式觸發(fā)發(fā)布。

發(fā)布測(cè)試階段包括boot軟件燒制、APP軟件下載、試運(yùn)行環(huán)境上的自動(dòng)測(cè)試等。如果成功，會(huì)進(jìn)入批量發(fā)布階段。批量發(fā)布只包括boot軟件的燒制、APP軟件下載。圖4是運(yùn)行發(fā)布流程的jenkins環(huán)境。

圖4G產(chǎn)品CI環(huán)境——發(fā)布環(huán)境

4結(jié)語(yǔ)

本文結(jié)合實(shí)際案例對(duì)持續(xù)交付系統(tǒng)進(jìn)行了研究和探索，可作為相關(guān)開(kāi)發(fā)和應(yīng)用的參考。希望軟件開(kāi)發(fā)團(tuán)隊(duì)能夠正確認(rèn)識(shí)和使用，從而高效地創(chuàng)造出具有國(guó)際競(jìng)爭(zhēng)力的高質(zhì)量產(chǎn)品。

參考文獻(xiàn)參考文獻(xiàn)：

[1]林鑫瀚.敏捷方法與小型團(tuán)隊(duì)的軟件開(kāi)發(fā)[J].軟件導(dǎo)刊，2009（9）：2931.

[2]陳亭華.敏捷方法在通訊軟件開(kāi)發(fā)中的應(yīng)用與研究[J].軟件導(dǎo)刊，2014（2）：9193.

[3]喬梁.持續(xù)交付：價(jià)值主張[EB/OL]. [20121110].博客園，http：//kb.cnblogs.com/page/163413/

[4]JEZ HUMBLE，DAVID FARLEY.持續(xù)交付，發(fā)布可靠軟件的系統(tǒng)方法[M].喬梁，譯.北京：人民郵電出版社，2011.

[5]LISA CRISPIN，JANET GREGORY.敏捷軟件測(cè)試：測(cè)試人員與敏捷團(tuán)隊(duì)的實(shí)踐指南[M].孫偉峰，崔康，譯.北京： 清華大學(xué)出版社，2010.

責(zé)任編輯（責(zé)任編輯：杜能鋼）endprint