張文林

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

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

DOIDOI：10.11907/rjdk.171744

中圖分類號：TP319文獻標識碼：A文章編號：16727800（2017）010015903

0引言

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

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

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

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

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

2持續(xù)交付階段

2.1提交階段

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

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

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

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

2.2自動化驗收測試階段

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

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

每個階段的自動化測試運行時間以及復雜性要適度。過長或過于復雜的自動化測試會影響執(zhí)行；自動化測試時間太長，會導致下一次自動化測試包含多次提交，難以及時準確發(fā)現(xiàn)問題，同時，提交的效率也會降低，因為大家會坐等上一次自動化測試的完成。

2.3手工測試階段

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

2.4發(fā)布階段

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

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

2.5度量

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

3實踐與應用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4結語

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

參考文獻參考文獻：

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

[2]陳亭華.敏捷方法在通訊軟件開發(fā)中的應用與研究[J].軟件導刊，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.敏捷軟件測試：測試人員與敏捷團隊的實踐指南[M].孫偉峰，崔康，譯.北京： 清華大學出版社，2010.

責任編輯（責任編輯：杜能鋼）endprint