持續交付及其在大型項目中的應用

張文林

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

關鍵詞：敏捷開發；持續集成（Continuous Integration， CI）；持續交付（Continuous Delivery， CD）；G產品；Jenkins環境

DOIDOI：10.11907/rjdk.171744

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

0引言

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

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

1持續交付系統方法

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

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

2持續交付階段

2.1提交階段

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

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

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

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

2.2自動化驗收測試階段

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

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

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

2.3手工測試階段

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

2.4發布階段

發布階段指在試運行環境上進行冒煙測試和集成測試。

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

2.5度量

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

3實踐與應用

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

3.1G產品配置管理

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

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

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

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

圖2G產品分支策略

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

3.2G產品自動化測試

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

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

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

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

3.3G產品手工測試

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

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

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

3.4G產品版本發布

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

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

圖4G產品CI環境——發布環境

4結語

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

參考文獻參考文獻：

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

[2]陳亭華.敏捷方法在通訊軟件開發中的應用與研究[J].軟件導刊，2014（2）：9193.

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

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

[5]LISA CRISPIN，JANET GREGORY.敏捷軟件測試：測試人員與敏捷團隊的實踐指南[M].孫偉峰，崔康，譯.北京： 清華大學出版社，2010.

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