基于DevOps能力模型的持續(xù)集成方法

董 昕，郭 勇，王 杰

(1.成都工業(yè)學(xué)院 計算機工程學(xué)院，四川 成都 611730；2.摩托羅拉系統(tǒng)(中國)有限公司成都分公司，四川 成都 611731；3.中國電子科技集團第29研究所，四川 成都 610036)

0 引 言

近年來，軟件的規(guī)模越來越大，復(fù)雜度也越來越高。較大規(guī)模和較高復(fù)雜度使集成變成了一件困難的事情，軟件項目團隊極可能會遇到下面的一些問題：

(1)研發(fā)人員要等很長時間才能看到自己提交的結(jié)果。如果研發(fā)人員嚴(yán)格遵守“頻繁提交”原則，則上百人的大型研發(fā)團隊將一直處于提交狀態(tài)，使集成服務(wù)器始終繁忙，某位研發(fā)人員必須等待其它研發(fā)人員提交的構(gòu)建通過后，才能知道自己的提交是否構(gòu)建成功、是否測試通過。

(2)一旦構(gòu)建失敗，研發(fā)人員將花費較長時間才知道這次失敗是否與自己提交的改動相關(guān)。

(3)測試人員不知道在哪里拿對應(yīng)的構(gòu)建來進行測試。

(4)項目經(jīng)理不確定測試人員是否在正確的運行環(huán)境上運行了正確的版本等。因此找到一種高效的等解決上述問題的持續(xù)集成方法就成了當(dāng)務(wù)之急。

文獻[1]提出可將代碼靜態(tài)分析工具Klocwork引入到持續(xù)集成系統(tǒng)中提高代碼質(zhì)量，但項目實踐發(fā)現(xiàn)Klocwork并不適合處理快節(jié)奏大代碼庫的持續(xù)集成系統(tǒng)。文獻[2]提出使用開源的托管平臺GitHub提高版本控制效率，但其只支持Git作為唯一的版本庫格式進行托管。文獻[3]提出利用NUnit單元測試框架實現(xiàn)自動化單元測試。上述文獻基于特定集成環(huán)境提出了某些方面問題的解決方案，但是沒有從系統(tǒng)層次解決大型軟件項目持續(xù)集成的根本問題。

本文在上述文獻研究及項目實踐基礎(chǔ)上，提出了基于DevOps能力模型的大規(guī)模持續(xù)集成方法，該方法從自動化、質(zhì)量保障及可視化3個維度出發(fā)，通過自動化使軟件構(gòu)建、測試、發(fā)布整個流程更加頻繁、快捷及可靠，通過可視化使項目各項數(shù)據(jù)形象直觀，加強軟件開發(fā)人員、質(zhì)量保障人員和運營維護人員的溝通合作。

1 RM項目持續(xù)集成系統(tǒng)

作為一種重要的軟件開發(fā)實踐，持續(xù)集成要求團隊研發(fā)成員頻繁集成其工作，通常要求每個成員每天至少完成一次集成。每一次集成都必須通過自動化構(gòu)建(包含編譯、發(fā)布、自動化測試)驗證，使得集成錯誤及早被發(fā)現(xiàn)[2]。本文給出了一種基于DevOps能力模型的以團隊基礎(chǔ)服務(wù)器(team foundation sever，TFS)為核心的持續(xù)集成的方法，并在數(shù)字集群通信系統(tǒng)對講機管理軟件(radio management，RM)開發(fā)項目中應(yīng)用并得到了驗證。

數(shù)字集群通信系統(tǒng)廣泛應(yīng)用于公共安全、交通運輸、能源和物流等領(lǐng)域。作為數(shù)字集群通信系統(tǒng)的手持設(shè)備，對講機為無線用戶提供語音和數(shù)據(jù)服務(wù)，在各行各業(yè)的指揮調(diào)度中發(fā)揮了重要作用。對講機管理系統(tǒng)(Radio Mana-gement，RM)為對講機用戶提供了計算機和對講機之間的編程接口。RM允許客戶修改對講機配置文件，使客戶能夠輕松地管理和更新對講機的軟件。該項目有下面幾個特點：

(1)項目團隊比較分散，除了中國之外，歐洲和美國也有部分開發(fā)人員；

(2)項目規(guī)模較大，有超過100人參與其中，代碼行數(shù)達到近百萬行；

(3)項目關(guān)系復(fù)雜，影響面較廣，涉及到固件(firmware)、多條產(chǎn)品線、軟件遺留系統(tǒng)的重用和架構(gòu)的重構(gòu)。

(4)也是最重要的一點，在采用DevOps能力模型方法之前，RM項目幾乎沒有自動化構(gòu)建、測試及版本控制技術(shù)，編碼、構(gòu)建、集成、測試、交付等還處于各自為政的狀態(tài)，沒有打通整個項目鏈條。

RM系統(tǒng)需要支持及兼容數(shù)款主流對講機型號，而且未采用持續(xù)集成方法，一個主版本通常需要約一百名工程師歷時近一年時間開發(fā)測試交付完成，效率較低。

1.1 常用的持續(xù)集成平臺

軟件開發(fā)生命周期過程隨著時間的推移而演變。開發(fā)團隊意識到定期構(gòu)建的重要性，開始了每周構(gòu)建。然后，當(dāng)每日構(gòu)建開始時，構(gòu)建變得越來越頻繁，甚至出現(xiàn)了每小時構(gòu)建。由于頻繁構(gòu)建的好處變得更加明顯，團隊需要更多的構(gòu)建。這是因為軟件開發(fā)的持續(xù)集成使軟件團隊獲得正式、可靠的構(gòu)建。因此，高效持續(xù)集成的關(guān)鍵實踐為以下幾點：只需要維護一個統(tǒng)一的源碼庫；支持自動化構(gòu)建；自行測試每次構(gòu)建[3]；每位研發(fā)人員每天都必須將代碼提交到主線上；每次提交后主線必須在集成服務(wù)器上被重新構(gòu)建；確保構(gòu)建快速便捷；測試在模擬環(huán)境中進行[4]；每位研發(fā)人員都能容易得到最新的可執(zhí)行文件；每位研發(fā)人員都能觀察到進度；部署自動化等[5]。由于開發(fā)人員和測試人員進行持續(xù)的同步工作，要求他們互相之間要不斷地更新和反饋消息，了解軟件質(zhì)量的實時狀況和快速地修復(fù)缺陷[6]?；谶@點，持續(xù)集成的自動化將發(fā)揮巨大的作用。

現(xiàn)階段持續(xù)集成自動化平臺較多，比如CruiseControl、Jenkins和Integrity等，百花齊放，各有千秋[7]。本文提出的基于DevOps能力模型持續(xù)集成新方法以微軟應(yīng)用程序生命周期管理服務(wù)器團隊基礎(chǔ)服務(wù)器即team foundation server(TFS)為核心，提供源代碼管理、報告、需求管理、項目管理、自動構(gòu)建、實驗室管理、測試和發(fā)布管理等功能，覆蓋了整個應(yīng)用程序生命周期，將在第二章詳細介紹該新方法的特點。

1.2 基于DevOps能力模型的持續(xù)集成

DevOps能力模型如圖1所示包含了3個部分：開發(fā)、測試和運維，它是三者的交集。DevOps能力模型的目的是通過高度自動化工具與流程，實現(xiàn)更好地優(yōu)化軟件開發(fā)(development，Dev)、測試(quality assurance，QA)、運維(operations，Ops)流程，開發(fā)運維一體化，使軟件構(gòu)建、測試、發(fā)布、運營、維護乃至整個生命周期管理更加快捷、頻繁和可靠。

圖1 DevOps能力模型

DevOps能力模型有以下幾點優(yōu)勢：

(1)代碼的提交直接觸發(fā)構(gòu)建及測試：消除等待時間，快速反饋軟件質(zhì)量；

(2)每個變化對應(yīng)一個交付管道：使問題定位和調(diào)試變得簡單；

(3)開發(fā)流程全程高效自動化：穩(wěn)定、快速、可預(yù)測交付結(jié)果；

(4)自動化回歸測試持續(xù)進行：提高軟件交付質(zhì)量；

(5)軟硬件設(shè)施和資源共享并按需提供分配：資源利用率最大化。

該模型聚焦于在一個大型組織內(nèi)實施持續(xù)集成必須遵循自動化、質(zhì)量保證、可視化、持續(xù)交付、技術(shù)運營、組織文化等方面所需要的能力，有的放矢地解決前面提到的各種問題并持續(xù)改進符合企業(yè)特點的持續(xù)集成系統(tǒng)。可以從中選取3～4點，作為能力模型的維度，并在每個維度上深化，持續(xù)改進使能力提升。該模型可根據(jù)相應(yīng)得分而分級(L1-L5，L1為最低級入門級，L5為最高級極致級)，如表1所示。表中CI能力得分滿分為100，分3個維度打分，分別是自動化、質(zhì)量保障和可視化，各項滿分為35、35和30分。總分低于20分即為L0無序級，不低于20分但低于40分即為L1入門級，不低于40分但低于60分即為L2進階級，不低于60分但低于80分即為L3高階級，不低于80分但低于90分即為L4精通級，不低于90分但低于100分即為L5極致級。

表1 DevOps能力模型

文中持續(xù)集成方法的實施和改進會緊扣DevOps能力模型的這些維度來描寫：自動化、質(zhì)量保障及測試、可視化，從這3個維度分別詳細闡述基于DevOps能力模型的持續(xù)集成新方法的特點及其在RM項目中的具體應(yīng)用及成效。

2 RM項目持續(xù)集成模型的3個維度

2.1 自動化

DevOps能力模型中第一個維度是自動化，其中最重要的是如何實現(xiàn)自動化開發(fā)及構(gòu)建(Dev)。如何減少編譯時間？如何增加每天的集成次數(shù)和編譯次數(shù)？如何創(chuàng)建一個穩(wěn)定的可以隨時發(fā)布的應(yīng)用程序代碼庫？如何實現(xiàn)自動化集成并且自動回滾有缺陷的代碼？為了回答這些問題，RM項目找到的解決方案是基于DevOps能力模型的自動化構(gòu)建系統(tǒng)。圖2顯示了RM項目的構(gòu)建系統(tǒng)的拓撲結(jié)構(gòu)。圖中構(gòu)建控制器(build controller)存儲和管理一個或多個構(gòu)建代理的服務(wù)。它將處理器密集型工作(如編譯代碼或運行測試)分發(fā)到池中的各個構(gòu)建代理進行處理。構(gòu)建控制器處理工作流，通常執(zhí)行大多數(shù)輕量級工作，例如確定構(gòu)建的名稱，在版本控制中創(chuàng)建標(biāo)簽，記錄注釋以及報告構(gòu)建狀態(tài)。因為構(gòu)建控制器通常不需要大量的處理器時間，所以虛擬機通常足以用作構(gòu)建控制器的平臺。每個構(gòu)建代理(build agent)專用于單個構(gòu)建控制器并由其控制。構(gòu)建代理的工作包括從版本控制庫中獲得文件、簽入文件、編譯源代碼及測試。當(dāng)組裝一個構(gòu)建系統(tǒng)時，可以從幾個代理開始。然后可在添加團隊成員時添加更多構(gòu)建代理，隨著代碼庫的增長和構(gòu)建系統(tǒng)的工作增加，進行構(gòu)建系統(tǒng)擴展[8]。TFS構(gòu)建系統(tǒng)的核心就在于構(gòu)建定義與其工作流程。構(gòu)建定義描述了構(gòu)建的過程，包括編譯哪些代碼項目的指令，什么樣的行動觸發(fā)構(gòu)建，運行什么測試，以及許多其它的選擇。構(gòu)建定義有一系列的定義需要填，就像一個代碼項目的屬性頁[9]。

TFS構(gòu)建系統(tǒng)的另一個獨創(chuàng)性在于構(gòu)建工作流程(build workflow)。構(gòu)建工作流程定義具體的構(gòu)建過程，比如給出編譯哪些代碼項目的指令、什么事件應(yīng)該觸發(fā)構(gòu)建以及運行什么測試。本質(zhì)上工作流程就是定義團隊基礎(chǔ)構(gòu)建(team foundation build，TFBuild)的構(gòu)建代碼、運行測試并運行其它程序如腳本的方式的XAML文件。每個構(gòu)建定義都有一個對應(yīng)的工作流程文件如圖3所示。使用TFBuild還可以創(chuàng)建和管理自動編譯和測試應(yīng)用程序并執(zhí)行其它重要功能的構(gòu)建過程，并使用構(gòu)建系統(tǒng)來支持持續(xù)集成的策略，或者進行更嚴(yán)格的質(zhì)量檢查，以防止質(zhì)量差的代碼“打破構(gòu)建”。

圖2 RM項目TFS構(gòu)建系統(tǒng)的拓撲結(jié)構(gòu)

2.2 質(zhì)量保障及測試(QA)

DevOps能力模型中第二個維度是質(zhì)量保障及測試。為了在任何時間點都可以向客戶交付可運行高品質(zhì)的軟件產(chǎn)品，需要建立持續(xù)集成和自動化測試配合的機制。集成和測試的整合，意味著代碼在合成到主干前，系統(tǒng)就可以捕獲新代碼的編譯錯誤或功能錯誤，并觸發(fā)代碼自動回滾，這是一套動態(tài)并且強大高效機制。

RM自動化測試平臺是以團隊基礎(chǔ)服務(wù)器(team foundation server，TFS)為核心搭建起來的，實現(xiàn)了用測試分組和并行化降低測試周期、測試集合管理、測試環(huán)境管理：自動部署到測試實驗室及不同級別測試：封閉簽入測試(gated test)、簽入后測試(post test)、用戶界面自動化測試(UI automation test)等。封閉簽入測試是其中具有獨創(chuàng)性的測試方法。圖4顯示了封閉簽入的具體過程。當(dāng)工程師提交代碼修改時，快速持續(xù)集成被觸發(fā)。如果編譯或封閉簽入測試失敗，將阻止代碼簽入，并將代碼回滾到測試通過的版本，系統(tǒng)還將自動觸發(fā)郵件告知機制，將編譯或封閉簽入測試錯誤信息通過郵件發(fā)送給提交代碼的工程師；如果通過編譯和封閉簽入測試，代碼將被簽入。封閉簽入過程提高代碼的質(zhì)量，而且避免了無意義的重復(fù)勞動和人工操作可能存在的潛在錯誤。代碼簽入后，簽入后測試將被觸發(fā)，測試報告將發(fā)送給提交者[10]。并且在夜間12點運行涉及范圍更廣、測試用例更多的自動化測試。

圖4 封閉簽入流程

如圖5所示，在RM測試框架中TFS負責(zé)安排自動化測試、實驗室部署和測試結(jié)果收集等一系列活動。測試框架中主要組件如下：測試管理器(test manager)、測試控制器(test controller)、測試代理(test agent)及實驗室管理器(lab manager)。測試管理器主要功能是為軟件測試人員和測試主管提供一個專用于管理和執(zhí)行測試計劃的工具，將測試計劃、測試集合和測試用例存儲于TFS中。它負責(zé)配置測試控制器，測試控制器負責(zé)配置測試代理并安排一個或多個測試代理以便執(zhí)行自動化測試。測試運行完后，測試控制器收集測試代理的測試結(jié)果數(shù)據(jù)。TFS保存這些數(shù)據(jù)便于生成測試報表。測試代理(Test Agent)是作為實驗室環(huán)境的一部分的工作站，實際測試由測試控制器控制并在測試代理上運行。事實上測試管理器充當(dāng)TFS客戶端界面來驅(qū)動自動化測試，這意味著在測試管理器運行測試計劃之前，必須正確設(shè)置TFS，測試控制器和測試代理。實驗室管理器主要用于生成標(biāo)準(zhǔn)測試環(huán)境使測試代理能順利部署構(gòu)建運行自動化測試。

圖5 RM測試框架

RM項目基于TFS搭建了自動化測試平臺，其工作流程共有7步：①確定測試環(huán)境，即多臺計算機的集合，其中每臺計算機都有特定的功能，軟件在環(huán)境上部署及執(zhí)行測試；②創(chuàng)建測試配置，測試管理器利用測試配置定義不同的測試場景；③創(chuàng)建或?qū)霚y試用例，測試用例由工作項標(biāo)識：手動創(chuàng)建測試用例工作項，并將它們與測試方法相關(guān)聯(lián)或者使用tcm命令從測試程序集(DLL)自動生成測試用例工作項；測試管理器可以通過測試中心跟蹤查詢功能，搜索存在的測試用例；④創(chuàng)建測試計劃，創(chuàng)建由查詢生成的多個測試用例組成的測試套件；⑤在測試管理器上運行自動化，確保選擇正確的選項：正確的構(gòu)建包含測試程序集及其依賴項、測試運行環(huán)境及要使用的測試設(shè)置；⑥構(gòu)建完成后觸發(fā)自動測試，新構(gòu)建完成后，可以在“進程”選項卡中指定如何根據(jù)默認(rèn)工作流模板執(zhí)行自動化測試；⑦得到可視化的測試結(jié)果，如圖6所示。圖中顯示測試結(jié)果的概況，比如基于某些功能模塊的測試集合的通過率和總的測試用例通過率等測試數(shù)據(jù)，可為進一步測試、持續(xù)集成及質(zhì)量改進提供重要依據(jù)。一旦測試失敗，一方面記錄會自動發(fā)送給代碼提交者和測試負責(zé)人，缺陷會被及時記錄及修復(fù)；另一方面快速定位到哪次提交的代碼影響了主干代碼的穩(wěn)定性，并可以使代碼快速回滾到上一個的穩(wěn)定版本。

圖6 自動化測試結(jié)果

該方法不僅支持回歸測試的全自動化，而且測試周期的大幅減小，實現(xiàn)了測試環(huán)境準(zhǔn)備、測試用例執(zhí)行的自動化，提高了測試效率。

2.3 可視化

DevOps能力模型中第3個維度是可視化。持續(xù)集成和改進需要依靠數(shù)據(jù)全面反映DevOps狀態(tài)的數(shù)據(jù)，并且可視化貫穿持續(xù)集成的全過程，因此需要建設(shè)可視化的能力?；贒evOps能力模型的可視化軟件的開發(fā)吸收了多種先進的開源技術(shù)的優(yōu)點而開發(fā)的。而其中，Python Flask是使用Python編寫的輕量級Web后端應(yīng)用框架；MongoDB是基于分布式文件存儲的數(shù)據(jù)庫；G2是阿里由純Javascript編寫的語義化圖表生成工具；React是臉書公司提供的響應(yīng)式(Reactive)和組件化(Composable)的視圖組件技術(shù)；AngularJS是谷歌設(shè)計和開發(fā)的一套功能全面的前端開發(fā)框架；jQuery是一個快速簡潔的JavaScript庫；Bootstrap是Web樣式CSS框架，它為HTML標(biāo)記語言提供了一種網(wǎng)格式的樣式描述方案，直觀定義了Web頁面元素的顯示方式[11]。在這里以質(zhì)量保障及測試(缺陷數(shù)量趨勢、缺陷生存周期和失敗的測試用例等)和項目完成度中的燃盡圖和產(chǎn)品代辦項為例，闡述如何進行可視化。

圖7就是可視化頁面中質(zhì)量保障及測試的結(jié)果。圖中左上角表示過去、現(xiàn)在和預(yù)測將來的缺陷數(shù)量。如果測試運行一段時間之后，缺陷數(shù)量趨于穩(wěn)定或不再增長。這說明測試比較充分，發(fā)現(xiàn)了絕大部分的缺陷，預(yù)計尚未發(fā)現(xiàn)的缺陷較少。相反，如果缺陷持續(xù)增加，說明極有可能還有更多的缺陷尚未發(fā)現(xiàn)，還需繼續(xù)測試，項目遠未達到交付標(biāo)準(zhǔn)。圖中右上角給出了缺陷生存周期和狀態(tài)等指標(biāo)，比如在最近7天發(fā)現(xiàn)的缺陷有59個已解決，有2個尚未解決，有3個推遲到下個交付解決，沒有處于監(jiān)控狀態(tài)的缺陷。圖中左下角表示最近20天內(nèi)每天失敗的測試用例的趨勢，可看出測試用例失敗的數(shù)量尚未減少，還需繼續(xù)加大力度分析測試結(jié)果，判斷是測試用例缺陷還是軟件缺陷。圖中右下角表示失敗的測試用例分布圖，反映不同的組件各有多少測試用例失敗。測試和開發(fā)人員可以判斷潛在問題較多的組件集中力量分析。通過這些直觀化的信息，團隊可以分析軟件質(zhì)量情況，解決缺陷，預(yù)測何時能結(jié)束測試交付產(chǎn)品。

圖7 質(zhì)量保障及測試可視化

在項目完成度方面，RM項目主要選取燃盡圖和產(chǎn)品代辦項等來反映項目完成情況。圖8左上角是項目某階段的燃盡圖，可看出現(xiàn)階段的進度領(lǐng)先于計劃預(yù)期，項目進展較順利；右上角是現(xiàn)階段優(yōu)先級最高的5個產(chǎn)品待辦項(product backlog item，PBI)。5個待辦項中，有1個工作量較大，占30個人月；3個工作量居中，占13-15個人月，1個工作量較小暫時忽略不計。可看出，優(yōu)先級最高的5個產(chǎn)品待辦項的總工作量為71個人月，整體基本可控，不會帶來太大的進度風(fēng)險。

圖8 某項目沖刺進展情況可視化

在引入可視化之前，團隊存在的一種典型的反模型是含糊不清的“完成”定義，開發(fā)人員迫于時間壓力可以僥幸少做一些功能或忽略一些潛在缺陷[12]，引發(fā)的功能障礙的例子就是：團隊簽入了許多功能點，沖刺結(jié)束時絕大多數(shù)功能點都是“幾乎完成”，但都有細小的模塊沒有實現(xiàn)。這導(dǎo)致產(chǎn)品負責(zé)人在軟件上市前無法判斷還剩余多少工作為真正完成，從而帶來了不可預(yù)測性、不確定性及未知的質(zhì)量風(fēng)險[13]。而自從團隊明確定義了項目完成度的關(guān)鍵因素，并以可視化的形式設(shè)置了需要認(rèn)真對待的“完成”標(biāo)準(zhǔn)，開發(fā)人員主觀或非主觀漏掉功能點并導(dǎo)致軟件不可上市的情況被消除。

3 持續(xù)集成新方法的使用成效

從項目實踐可知，基于DevOps能力模型的持續(xù)集成新方法能顯著縮短構(gòu)建周期和軟件版本控制的時間。如圖9所示，Paradise RM 2.3項目使用了該方法后進行軟件版本控制的時間從之前未使用該方法的手工集成150分鐘縮短到3分鐘，效率提升98%；構(gòu)建周期從之前未使用該方法的平均270分鐘縮短到80分鐘，效率提升70%。為了驗證該方法的成效，將該方法移植到Tetra RM項目，使用了該方法軟件版本控制的時間從之前未使用該方法的48分鐘縮短到3分鐘，效率提升近94%；構(gòu)建周期從之前未使用該方法的平均109分鐘縮短到40分鐘，效率提升約63%。由兩個項目的實踐得到結(jié)論，采用DevOps能力模型持續(xù)集成新方法使RM項目構(gòu)建周期和軟件版本控制時間顯著降低，效率顯著提高。

圖9 所提方法使用前后構(gòu)建周期和軟件版本控制時間比較

基于下面幾個方面的分析，可以得出RM持續(xù)集成系統(tǒng)的特點：

(1)性能方面，該方法的每一步都采用了自動化技術(shù)，能快速完成。這里將持續(xù)集成可分為兩類：快速持續(xù)集成和全面持續(xù)集成?？焖俪掷m(xù)集成可以實現(xiàn)立等可取(如果不包括可用性測試可以在5分鐘內(nèi)完成)，而且支持封閉簽入，如果包括可用性測試可以10分鐘內(nèi)完成。全面持續(xù)集成如果不包括測試可以在30分鐘內(nèi)完成。其中測試可以在其它專用測試機上部署和執(zhí)行，測試時長是變化的，依賴于團隊選擇測試用例的策略和不同目的的測試類型，還可以通過在多個測試機上分布式運行測試用例來縮短測試周期。

(2)質(zhì)量保障及測試極大地提高了生產(chǎn)效率和軟件質(zhì)量。如果沒有一個穩(wěn)固和及時反饋的質(zhì)量系統(tǒng)，持續(xù)集成就是一個紙老虎。該方法預(yù)先創(chuàng)建好測試用例集合，根據(jù)測試目標(biāo)和功能自動選擇測試集合并監(jiān)控測試是否通過，如果通過將測試結(jié)果保存至測試結(jié)果庫中。如果測試失敗，通過自動發(fā)送郵件通知和報告等機制，幫助開發(fā)人員快速定位問題，找出問題原因，修復(fù)問題并通過測試。

(3)該方法還實現(xiàn)了非常有意義和強大的可視化及報告功能，包括：在持續(xù)集成構(gòu)建服務(wù)器的啟動/關(guān)機測量；構(gòu)建請求和持續(xù)集成服務(wù)器的響應(yīng)時間統(tǒng)計[14]；需要注意的突出問題的報警：構(gòu)建代理的短缺；過于頻繁的簽入代碼導(dǎo)致持續(xù)集成資源短缺，能定位到特定的構(gòu)建和發(fā)起者；可能是由于糟糕的設(shè)計或編碼引起的與之前構(gòu)建相比太長的周期。RM持續(xù)集成最終實現(xiàn)了團隊按計劃構(gòu)建，項目按計劃運行，質(zhì)量有保證；能夠向個人、團隊/項目發(fā)起報告。

(4)可用性方面，該方法實現(xiàn)了構(gòu)建服務(wù)器的相互備份，物理位置在不同國家的服務(wù)器互為備份，當(dāng)某臺服務(wù)器關(guān)閉時，另一臺支持自動切換。當(dāng)出現(xiàn)故障服務(wù)器恢復(fù)正常再次運行時，構(gòu)建服務(wù)器可以自動切換，提高了系統(tǒng)可靠性[15]。

(5)該方法還實現(xiàn)了硬件資源的高效利用：一方面是充分利用了虛擬機，能夠在Hyper-V環(huán)境中部署復(fù)雜的應(yīng)用程序，支持構(gòu)建自動化及測試自動化，并且按需動態(tài)分配資源；另一方面使24小時全天候運行狀態(tài)成為現(xiàn)實。

該項目牽涉多條產(chǎn)品線由幾個子項目組成，是一個為期3年的產(chǎn)品規(guī)劃。重建的RM系統(tǒng)對未來的集群通信系統(tǒng)無線終端設(shè)備的產(chǎn)品線發(fā)展有重大意義。在采用DevOps能力模型方法之前，RM項目幾乎沒有自動化構(gòu)建、測試及版本控制技術(shù)，編碼、構(gòu)建、集成、測試、交付等還處于各自為政的狀態(tài)，沒有打通這一鏈條，處于DevOps能力模型的無序級。采用DevOps能力模型方法之后，RM項目有效利用了各項自動化技術(shù)，加強了質(zhì)量保障及測試，實現(xiàn)了數(shù)據(jù)可視化，發(fā)動全體人員建設(shè)持續(xù)集成系統(tǒng)，構(gòu)建了一個相對完善的系統(tǒng)，基本達到了DevOps能力模型中的精通級。

項目實踐中采用DevOps能力模型方法來實現(xiàn)持續(xù)集成，該方法實現(xiàn)了RM自動化生命周期管理，其中包括：封閉簽入、編譯/構(gòu)建、靜態(tài)分析、單元測試、代碼混淆、安裝包生成、安裝包部署、集成測試、黑盒測試和錯誤報告。通過RM項目實踐，驗證該方法極大提高了軟件發(fā)布效率。從2013年至今由于使用該方法使研發(fā)成本減少了40%，將原來4個月的迭代周期縮短到1個月，并且實現(xiàn)軟件每天可以發(fā)布。并且RM項目是一個由跨越5個國家、3大洲和3條產(chǎn)品線的100多位開發(fā)人員的團隊組成的大規(guī)模軟件項目。該方法成功完成了對100萬行代碼、27年歷史的對講機管理系統(tǒng)架構(gòu)的重構(gòu)，并且兼容市面上主流對講機的所有功能，大大減少了軟件人工干預(yù)程度，較大程度地提高了軟件開發(fā)集成發(fā)布效率。

值得特別指出的是該方法顯著地提高了軟件質(zhì)量并降低了項目風(fēng)險。經(jīng)過集成測試每個改動簽入的問題都會被更早地發(fā)現(xiàn)。長時間的集成不再存在，盲區(qū)被徹底消除了。在任何時間都知道項目的進展，什么能運轉(zhuǎn)，什么不能運轉(zhuǎn)，系統(tǒng)里有什么明顯的問題，這些都一目了然。持續(xù)集成不能防止問題的產(chǎn)生，但明顯簡化定位和修復(fù)問題工作。由此可見，該方法使軟件開發(fā)工作更便捷，在軟件開發(fā)生命周期中的每個環(huán)節(jié)都能獲得可部署的軟件，并且能及早發(fā)現(xiàn)缺陷，縮短了開發(fā)時間，降低了軟件研發(fā)成本。通過該方法，軟件研發(fā)團隊可以降低風(fēng)險及減少重復(fù)性勞動，使得整個研發(fā)團隊能更好地掌握項目的狀態(tài)，在資源有限的情況下按時地保質(zhì)保量地順利完成項目。

通過項目實踐，可看出基于DevOps能力模型持續(xù)集成方法具備下列這些優(yōu)點：①當(dāng)開發(fā)、測試及運維人員處于分布式開發(fā)環(huán)境中，持續(xù)集成是一種很好的方式確保開發(fā)人員正在構(gòu)建的構(gòu)建是最新的；②連續(xù)集成能減少回歸次數(shù)；③開發(fā)人員能盡早捕獲構(gòu)建中斷，不必等待一天或一周的結(jié)束才了解某個簽入對構(gòu)建的影響；④在軟件生命周期中集成測試提前進行，每次簽入都要進行集成測試，盡早發(fā)現(xiàn)問題；⑤持續(xù)集成能實現(xiàn)更好的開發(fā)過程，每個開發(fā)者都要對構(gòu)建負責(zé)，而且總是有一個最新最好的構(gòu)建，用于演示和展示等。當(dāng)然，該方法也有一些不足之處，比如：持續(xù)集成會增加維護開銷；需要開發(fā)人員改變心態(tài)；簽入直接導(dǎo)致代碼備份，因為程序員無法簽入部分完成的代碼等。

為了更好地闡述本文新方法的優(yōu)勢，將該方法與傳統(tǒng)方法進行對比分析。由于Jenkins方法在業(yè)界使用最廣泛，最具有代表性，因此將該方法與Jenkins方法從3個方面做了對比分析，結(jié)果見表2。從表2的幾個方面比較可見，基于DevOps能力模型持續(xù)集成方法與現(xiàn)有較常用的持續(xù)集成平臺Jenkins比較，前者具有以下一些優(yōu)點：插件實用性較高，界面友好，清爽簡潔，代碼構(gòu)建支持更換代理，構(gòu)建流程較清晰。但是也有一些不足比如插件不夠豐富，后期可以豐富其插件庫，來進一步提升該方法的優(yōu)越性。

表2 本文方法與Jenkins方法比較

4 結(jié)束語

綜上所述，該持續(xù)集成方法提出了DevOps能力模型，并且從自動化、質(zhì)量保障及可視化等維度出發(fā)，實現(xiàn)了多個產(chǎn)品且每個產(chǎn)品多版本的軟件開發(fā)、測試及運維的高效融合，提高了開發(fā)效率，降低了項目質(zhì)量風(fēng)險。實踐結(jié)果表明，該方法值得在其它大規(guī)模軟件開發(fā)項目中推廣和部署。在今后的研發(fā)項目中，團隊前進的方向為實現(xiàn)產(chǎn)品隨時可發(fā)布，努力做到極致級別的持續(xù)集成。