張文林

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

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

DOIDOI：10.11907/rjdk.171744

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

0引言

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

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

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

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

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

2持續(xù)交付階段

2.1提交階段

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

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

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

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

2.2自動化驗(yàn)收測試階段

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

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

每個階段的自動化測試運(yùn)行時間以及復(fù)雜性要適度。過長或過于復(fù)雜的自動化測試會影響執(zhí)行；自動化測試時間太長，會導(dǎo)致下一次自動化測試包含多次提交，難以及時準(zhǔn)確發(fā)現(xiàn)問題，同時，提交的效率也會降低，因?yàn)榇蠹視壬弦淮巫詣踊瘻y試的完成。

2.3手工測試階段

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

2.4發(fā)布階段

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

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

2.5度量

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

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

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

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

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

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

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

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

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

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

3.2G產(chǎn)品自動化測試

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

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

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

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

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

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

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

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

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

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

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

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

4結(jié)語

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

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

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

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

[3]喬梁.持續(xù)交付：價值主張[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.敏捷軟件測試：測試人員與敏捷團(tuán)隊(duì)的實(shí)踐指南[M].孫偉峰，崔康，譯.北京： 清華大學(xué)出版社，2010.

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