王紅蕾

(青島科技大學(xué) 信息科學(xué)技術(shù)學(xué)院,青島 266061)

隨著互聯(lián)網(wǎng)市場競爭日趨激烈,市場逐步細(xì)分促使產(chǎn)品的個(gè)性化需求不斷增加,眾多互聯(lián)網(wǎng)產(chǎn)品如何在激烈的市場競爭中獲得用戶青睞,能夠快速適應(yīng)市場需求變化并能實(shí)現(xiàn)高質(zhì)量持續(xù)交付是關(guān)鍵.為適應(yīng)不斷變化的市場需求,產(chǎn)品的持續(xù)交付需要重復(fù)整合需求分析、設(shè)計(jì)、編碼、測試、部署和維護(hù)各階段工作,大量重復(fù)、缺乏協(xié)作的工作嚴(yán)重制約團(tuán)隊(duì)效率和產(chǎn)品質(zhì)量提高,DevOps 模式下的pipeline 流水線可以實(shí)現(xiàn)從版本控制庫到交付用戶過程的自動(dòng)化[1],成為互聯(lián)網(wǎng)產(chǎn)品開發(fā)與管理的可行途徑.

1 國內(nèi)外研究現(xiàn)狀

近年來,DevOps 在國內(nèi)外已有廣泛的研究和實(shí)踐,并在不同領(lǐng)域、不同行業(yè)證實(shí)基于DevOps 模式的項(xiàng)目研發(fā),在系統(tǒng)質(zhì)量控制和縮短客戶的交付響應(yīng)時(shí)間上有突出的表現(xiàn)[2-4],可以顯著提升產(chǎn)品持續(xù)交付的質(zhì)量和效率[2,4,5].然而,DevOps 的實(shí)踐沒有固定模式,受制于公司的規(guī)模、架構(gòu)和文化,呈現(xiàn)多樣性特征.Roche結(jié)合自己在Amazon,Adobe 公司大型項(xiàng)目研發(fā)經(jīng)驗(yàn),提出了一種多角色協(xié)同的DevOps 模式,并研究了該模式下的質(zhì)量保障體系[6];Kamuto 等研究了大型分布式項(xiàng)目中DevOps 實(shí)施的各類制約因素[7];Rajkumar 等研究了DevOps 文化在基于云環(huán)境下的產(chǎn)品交付和開發(fā)的影響,指出DevOps 模式需要對(duì)組織機(jī)構(gòu)、管理策略等進(jìn)行較大的改變[8].而由于交付的頻繁,能夠設(shè)計(jì)符合企業(yè)實(shí)際的自動(dòng)化交付方案,確保軟件處于一個(gè)穩(wěn)定的、可隨時(shí)發(fā)布的狀態(tài),是持續(xù)交付實(shí)踐的關(guān)鍵.Krusche等提出了利于持續(xù)交付工作流快速交付產(chǎn)品的模型[9].Düllmann 等提出一種基于DevOps 實(shí)踐的高可靠性的持續(xù)交付流水線實(shí)現(xiàn)方案[10],Shah 等探討了采用Jenkins、GIT 等自動(dòng)化工具構(gòu)造持續(xù)交付流水線的可能模式[11].文獻(xiàn)[4,12] 調(diào)研了國內(nèi)外眾多知名企業(yè)DevOps 實(shí)踐,實(shí)踐過程中使用的自動(dòng)化工具進(jìn)行調(diào)查,其中Jenkins、GIT、Docker 被廣泛應(yīng)用[13].隨著DevOps的日益成熟,其逐漸成為大型互聯(lián)網(wǎng)企業(yè)首選模式,而中小規(guī)模企業(yè)實(shí)施持續(xù)交付時(shí)完全借鑒現(xiàn)有的DevOps模式,難以落地.一方面企業(yè)規(guī)模、管理模式、人員結(jié)構(gòu)存在差異,完全拋棄企業(yè)原有的輔助工具、管理模式成本較大;另一方面隨著發(fā)布頻率提高,產(chǎn)品維護(hù)和升級(jí)操作頻繁,身兼數(shù)職的人員難以完成工作.

針對(duì)DevOps 模式在中小規(guī)模企業(yè)實(shí)踐存在的問題,提出了一種輕量級(jí)的持續(xù)交付方案,將軟件交付流程進(jìn)行優(yōu)化,通過調(diào)查問卷的形式了解區(qū)域互聯(lián)網(wǎng)企業(yè)的DevOps 應(yīng)用現(xiàn)狀和特點(diǎn),以企業(yè)實(shí)踐和組織成員訪談?wù)撟C了方案的可行性

2 輕量級(jí)持續(xù)交付方案設(shè)計(jì)

以靈活的自動(dòng)化形式實(shí)現(xiàn)從版本控制庫到交付用戶的方案,首先要選取相應(yīng)的工具,目前在版本控制、代碼掃描、自動(dòng)化測試、構(gòu)建和部署等方面的主流使用工具如表1所示.

以開源性、可擴(kuò)展性和操作簡便性為原則,本文使用GIT[14]作為版本控制工具以Jenkins[13]為持續(xù)交付服務(wù),集成sonar 進(jìn)行增量式代碼掃描,以Maven 完成自動(dòng)編譯和打包,在Robot Framework[15]框架下編寫自動(dòng)化測試用例.

表1 主流工具對(duì)比

新功能的開發(fā)或缺陷問題的修復(fù)產(chǎn)生軟件版本的迭代,開發(fā)人員將產(chǎn)生迭代的代碼提交到版本控制庫時(shí)便觸發(fā)一次產(chǎn)品的交付.這包括將代碼集成后交付給測試人員進(jìn)行人工驗(yàn)證以及在生產(chǎn)環(huán)境上線部署交付到用戶使用.由于項(xiàng)目的頻繁更新迭代,將記錄交付測試、用戶的流水線腳本和測試腳本以版本庫的形式實(shí)現(xiàn)保證了交付過程能夠持續(xù)進(jìn)行[4],一個(gè)完整的輕量級(jí)持續(xù)交付方案如圖1所示.

(1)無論是新功能開發(fā)完成還是線上問題修復(fù)均需要在測試環(huán)境驗(yàn)收通過才能交付用戶,項(xiàng)目交付到測試人員時(shí),代碼編寫規(guī)范、空指針、內(nèi)存溢出等規(guī)范性和阻塞性問題要盡早發(fā)現(xiàn),同時(shí)保證本次提交不能對(duì)以往版本產(chǎn)生影響,因此項(xiàng)目遠(yuǎn)程倉庫更新后,持續(xù)交付服務(wù)自動(dòng)調(diào)用已編寫有代碼審查、單元測試、打包和回歸測試的流水線構(gòu)建腳本.執(zhí)行完成后以郵件的形式通知測試和開發(fā)人員,若執(zhí)行失敗開發(fā)人員進(jìn)行代碼修復(fù),反之成功則將當(dāng)前版本打包歸檔,測試人員開始冒煙測試和系統(tǒng)測試,測試通過等待上線.交付到測試的流水線腳本結(jié)構(gòu)如圖2所示.

圖1 輕量級(jí)持續(xù)交付方案

圖2 交付測試的流水線腳本結(jié)構(gòu)

(2)為了實(shí)現(xiàn)后續(xù)快速上線,執(zhí)行交付用戶的流水線過程如下:

① 代碼獲取:新代碼在測試環(huán)境驗(yàn)收通過后手動(dòng)合并到主分支,通過git clone 的命令獲取主分支上的代碼以便在后續(xù)的階段中部署到生產(chǎn)環(huán)境.

② 構(gòu)建:Maven 項(xiàng)目的構(gòu)建以mvn clean package命令完成編譯和打包的過程.

③ 部署:部署時(shí)實(shí)行停機(jī)更新時(shí)是先停止服務(wù)的進(jìn)程,把項(xiàng)目打包完成后將war 包放到指定路徑啟動(dòng)服務(wù).

④ 通知上線結(jié)果,應(yīng)用構(gòu)建部署成功則通知相關(guān)人員并將當(dāng)前版本的包歸檔,若部署失敗則相關(guān)人員根據(jù)構(gòu)建日志進(jìn)行問題修復(fù).

交付用戶的流水線過程如圖3所示.

圖3 交付用戶的流水線結(jié)構(gòu)

3 實(shí)驗(yàn)

3.1 行業(yè)調(diào)查

為調(diào)查青島市互聯(lián)網(wǎng)企業(yè)組織現(xiàn)狀,反映DevOps應(yīng)用特點(diǎn),為企業(yè)實(shí)踐提供組織管理依據(jù),本文通過第三方調(diào)查平臺(tái)發(fā)起調(diào)查問卷.問卷設(shè)置問題均為客觀選擇題,第一部分組織管理問題,包括:組織實(shí)施模型、團(tuán)隊(duì)自動(dòng)化程度、員工培訓(xùn)投入、團(tuán)隊(duì)DevOps經(jīng)驗(yàn),第二部分為IT 組織性能調(diào)查,問題包括項(xiàng)目交付周期和部署頻率.

問卷中將組織模型分布設(shè)置為4 類,主要探討不同模型在項(xiàng)目交付上的區(qū)別.其中瀑布模型依次進(jìn)行設(shè)計(jì)、開發(fā)、測試和運(yùn)維過程,開發(fā)周期長,項(xiàng)目成果整體交付[16];敏捷和瀑布混合模型下交付方式視項(xiàng)目需求而定,在新功能的引入和缺陷修復(fù)中使用敏捷方法[17];敏捷模型項(xiàng)目采用敏捷開發(fā)方法逐漸迭代[18];DevOps 模型則高度引入自動(dòng)化測試,實(shí)現(xiàn)持續(xù)集成和持續(xù)交付.

經(jīng)過統(tǒng)計(jì)共收到72 份有效的問卷,其中僅有9%的企業(yè)組織過程能采用到DevOps 過程模型,有24%的企業(yè)能夠?qū)嵤┟艚菽Ｐ?而67%的互聯(lián)網(wǎng)企業(yè)仍然采用瀑布模型或瀑布模型與敏捷相混合的過程.組織模型的分布如圖4所示.

① 員工培訓(xùn)投入包括:未對(duì)員工進(jìn)行任何新技術(shù)培訓(xùn);關(guān)注員工業(yè)務(wù)知識(shí)培訓(xùn);定期組織技術(shù)分享會(huì)議.在統(tǒng)計(jì)中85%的DevOps 企業(yè)定期組織技術(shù)分享會(huì)議,占整個(gè)調(diào)查的30%.

② 自動(dòng)化程度:無自動(dòng)化工具;僅使用自動(dòng)化進(jìn)行問題驗(yàn)證;有涉及集成和交付的自動(dòng)化崗位.在統(tǒng)計(jì)中僅27.8%的公司能夠設(shè)立專職的自動(dòng)化崗位,DevOps企業(yè)均有專職的自動(dòng)化崗位,占其中的35%.

③ 團(tuán)隊(duì)DevOps 經(jīng)驗(yàn)調(diào)查的問題包括:無相關(guān)經(jīng)驗(yàn);僅對(duì)DevOps 有學(xué)習(xí)了解;關(guān)鍵領(lǐng)導(dǎo)崗位有DevOps實(shí)踐經(jīng)驗(yàn).其中對(duì)DevOps 有學(xué)習(xí)了解或經(jīng)驗(yàn)的占總數(shù)的43.05%,而所有的DevOps 應(yīng)用企業(yè)關(guān)鍵領(lǐng)導(dǎo)崗位均有DevOps 實(shí)踐經(jīng)驗(yàn).

圖4 組織模型分布

結(jié)論1:DevOps 在青島互聯(lián)網(wǎng)企業(yè)中應(yīng)用較少.而企業(yè)要成功實(shí)施DevOps,一方面要重視團(tuán)隊(duì)技術(shù)培訓(xùn)的投入提高組織自動(dòng)化程度,另一方面,一個(gè)有較強(qiáng)領(lǐng)導(dǎo)力的團(tuán)隊(duì)領(lǐng)導(dǎo)也是DevOps 能夠成功實(shí)施的重要因素.

如圖5所示,在組織模型與交付周期關(guān)系的圖表中,瀑布模型或瀑布與敏捷混合的兩個(gè)過程中分別有30%和7.69%的企業(yè)存在項(xiàng)目延期的情況,分別有40%和61.65%的企業(yè)交付周期在3～4 周完成交付,僅有30%和30.77%的企業(yè)交付周期能實(shí)現(xiàn)2 周完成一次交付,無企業(yè)在這兩種形式下進(jìn)行1 周完成多次的項(xiàng)目交付,而敏捷模型和DevOps 模型的企業(yè)中有12.50%和66.67%的企業(yè)能在一周完成多次的交付.

圖5 組織模型與交付周期

如圖6在組織模型與部署頻率關(guān)系的圖表中,采用瀑布模型的企業(yè)70%的部署頻率為每月部署一次,無企業(yè)的部署頻率在一周部署多次;瀑布和敏捷混合的組織模型中相比較瀑布模型的部署頻率更多的達(dá)到每2 周部署一次,仍然無企業(yè)實(shí)現(xiàn)1 周部署多次的情況;在敏捷模型過程中75%的企業(yè)能實(shí)現(xiàn)1 周部署一次,無企業(yè)部署按月進(jìn)行,相比較前2 種的頻率有所增高,DevOps 模型中首次出現(xiàn)1 周部署多次的情況,所占比例為33.33%但大部分即66.67%的部署頻率在一周部署一次,相比較前3 者的部署頻率最高.

圖6 組織模型與部署頻率

結(jié)論2:隨著企業(yè)采用的組織模型由瀑布模型向敏捷模型、DevOps 模型的過程轉(zhuǎn)變項(xiàng)目交付周期逐漸縮短,相對(duì)應(yīng)的部署頻率也就越高,這與敏捷模型和DevOps 模型提倡項(xiàng)目迭代和持續(xù)集成的目標(biāo)是一致的.

3.2 輕量級(jí)持續(xù)交付方案企業(yè)應(yīng)用分析

自2019年1月,S 公司開始在原有敏捷開發(fā)的基礎(chǔ)上采用輕量級(jí)的交付方案,并在持續(xù)交付服務(wù)基礎(chǔ)上研發(fā)了持續(xù)交付管理平臺(tái),如圖7所示的流水線管理模塊,在新建一條流水線后可靈活選擇驗(yàn)證過程和回歸測試用例,對(duì)交付流水線進(jìn)行修改、查看詳情、執(zhí)行流水線以及刪除操作.如圖8所示的項(xiàng)目迭代管理是對(duì)上線功能的版本管理同時(shí)進(jìn)行發(fā)布.

圖7 流水線管理模塊

圖8 項(xiàng)目迭代管理

經(jīng)過一段時(shí)間的實(shí)踐在項(xiàng)目交付能力和交付質(zhì)量上有較明顯提升.如圖9所示,以交付周期和部署頻率體現(xiàn)項(xiàng)目的交付能力,敏捷方法的交付周期和部署頻率在10 天左右,采用輕量級(jí)方案后交付周期和部署頻率有下降到6 天作用,交付能力得到提高.

項(xiàng)目變更失敗比例是指在項(xiàng)目上線時(shí)需要進(jìn)行系統(tǒng)修復(fù)的比例,包括代碼回滾、服務(wù)重啟、缺陷修復(fù)等現(xiàn)象,以項(xiàng)目變更失敗比例來衡量項(xiàng)目交付質(zhì)量.如圖10所示,采用流水線方案前失敗比例在8.5%上下浮動(dòng),而采用方案后交付過程進(jìn)行標(biāo)準(zhǔn)化操作,降低了人為操作失誤,同時(shí)測試更加充分,失敗比例逐步降至4%左右.

圖9 項(xiàng)目交付能力對(duì)比

圖10 項(xiàng)目變更失敗比例對(duì)比

修復(fù)問題的過程是開發(fā)人員修改完代碼后交由測試人員進(jìn)行驗(yàn)證,驗(yàn)證通過交由運(yùn)維部署上線,如圖11所示,原敏捷過程通過查找代碼提交記錄和運(yùn)維記錄可粗略統(tǒng)計(jì)平均在3.5 小時(shí).而采用流水線形式之后自動(dòng)化回歸驗(yàn)證通過可直接上線,用時(shí)逐步下降到2.5 小時(shí).

圖11 問題修改平均時(shí)長對(duì)比

4 總結(jié)

本文在敏捷過程的基礎(chǔ)上將項(xiàng)目交付中重復(fù)度高的工作利用自動(dòng)化工具,使用流水線形式實(shí)現(xiàn),通過問卷調(diào)查明確企業(yè)要實(shí)施DevOps 需要進(jìn)行的組織管理改進(jìn),對(duì)存在角色重疊的互聯(lián)網(wǎng)企業(yè)使用流水線前后的組織性能包括項(xiàng)目交付能力和交付質(zhì)量進(jìn)行對(duì)比,為企業(yè)實(shí)施DevOps,實(shí)現(xiàn)持續(xù)交付提供了參考.

本文的不足之處主要體現(xiàn)在兩個(gè)方面,一方面在流水線方案中,一個(gè)流水線執(zhí)行完測試驗(yàn)證需要上線時(shí)要進(jìn)行申請,經(jīng)過專人確認(rèn)后方能上線,需要申請的原因是當(dāng)有多個(gè)功能需要上線時(shí)防止項(xiàng)目代碼相互覆蓋,如何有效的解決上線等待問題將是今后的研究方向.另一方面本文調(diào)查問卷僅對(duì)青島市企業(yè)進(jìn)行統(tǒng)計(jì)且企業(yè)數(shù)量相對(duì)偏少,在今后將對(duì)不同地區(qū)互聯(lián)網(wǎng)企業(yè)的持續(xù)關(guān)注,不斷完善調(diào)查報(bào)告.