基于DevOps的輕量級持續交付方案①

王紅蕾

(青島科技大學 信息科學技術學院,青島 266061)

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

1 國內外研究現狀

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

針對DevOps 模式在中小規模企業實踐存在的問題,提出了一種輕量級的持續交付方案,將軟件交付流程進行優化,通過調查問卷的形式了解區域互聯網企業的DevOps 應用現狀和特點,以企業實踐和組織成員訪談論證了方案的可行性

2 輕量級持續交付方案設計

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

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

表1 主流工具對比

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

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

圖1 輕量級持續交付方案

圖2 交付測試的流水線腳本結構

(2)為了實現后續快速上線,執行交付用戶的流水線過程如下:

① 代碼獲取:新代碼在測試環境驗收通過后手動合并到主分支,通過git clone 的命令獲取主分支上的代碼以便在后續的階段中部署到生產環境.

② 構建:Maven 項目的構建以mvn clean package命令完成編譯和打包的過程.

③ 部署:部署時實行停機更新時是先停止服務的進程,把項目打包完成后將war 包放到指定路徑啟動服務.

④ 通知上線結果,應用構建部署成功則通知相關人員并將當前版本的包歸檔,若部署失敗則相關人員根據構建日志進行問題修復.

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

圖3 交付用戶的流水線結構

3 實驗

3.1 行業調查

為調查青島市互聯網企業組織現狀,反映DevOps應用特點,為企業實踐提供組織管理依據,本文通過第三方調查平臺發起調查問卷.問卷設置問題均為客觀選擇題,第一部分組織管理問題,包括:組織實施模型、團隊自動化程度、員工培訓投入、團隊DevOps經驗,第二部分為IT 組織性能調查,問題包括項目交付周期和部署頻率.

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

經過統計共收到72 份有效的問卷,其中僅有9%的企業組織過程能采用到DevOps 過程模型,有24%的企業能夠實施敏捷模型,而67%的互聯網企業仍然采用瀑布模型或瀑布模型與敏捷相混合的過程.組織模型的分布如圖4所示.

① 員工培訓投入包括:未對員工進行任何新技術培訓;關注員工業務知識培訓;定期組織技術分享會議.在統計中85%的DevOps 企業定期組織技術分享會議,占整個調查的30%.

② 自動化程度:無自動化工具;僅使用自動化進行問題驗證;有涉及集成和交付的自動化崗位.在統計中僅27.8%的公司能夠設立專職的自動化崗位,DevOps企業均有專職的自動化崗位,占其中的35%.

③ 團隊DevOps 經驗調查的問題包括:無相關經驗;僅對DevOps 有學習了解;關鍵領導崗位有DevOps實踐經驗.其中對DevOps 有學習了解或經驗的占總數的43.05%,而所有的DevOps 應用企業關鍵領導崗位均有DevOps 實踐經驗.

圖4 組織模型分布

結論1:DevOps 在青島互聯網企業中應用較少.而企業要成功實施DevOps,一方面要重視團隊技術培訓的投入提高組織自動化程度,另一方面,一個有較強領導力的團隊領導也是DevOps 能夠成功實施的重要因素.

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

圖5 組織模型與交付周期

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

圖6 組織模型與部署頻率

結論2:隨著企業采用的組織模型由瀑布模型向敏捷模型、DevOps 模型的過程轉變項目交付周期逐漸縮短,相對應的部署頻率也就越高,這與敏捷模型和DevOps 模型提倡項目迭代和持續集成的目標是一致的.

3.2 輕量級持續交付方案企業應用分析

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

圖7 流水線管理模塊

圖8 項目迭代管理

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

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

圖9 項目交付能力對比

圖10 項目變更失敗比例對比

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

圖11 問題修改平均時長對比

4 總結

本文在敏捷過程的基礎上將項目交付中重復度高的工作利用自動化工具,使用流水線形式實現,通過問卷調查明確企業要實施DevOps 需要進行的組織管理改進,對存在角色重疊的互聯網企業使用流水線前后的組織性能包括項目交付能力和交付質量進行對比,為企業實施DevOps,實現持續交付提供了參考.

本文的不足之處主要體現在兩個方面,一方面在流水線方案中,一個流水線執行完測試驗證需要上線時要進行申請,經過專人確認后方能上線,需要申請的原因是當有多個功能需要上線時防止項目代碼相互覆蓋,如何有效的解決上線等待問題將是今后的研究方向.另一方面本文調查問卷僅對青島市企業進行統計且企業數量相對偏少,在今后將對不同地區互聯網企業的持續關注,不斷完善調查報告.