基于DevOps的流水線可視化自由編排方案與實踐

居彬 王啟威 謝承翰

（中電鴻信信息科技有限公司 江蘇省南京市 210029）

1 引言

某電信企業(yè)承接多種類型產(chǎn)品和項目的開發(fā)運維工作，具體歸納有如下幾點：

（1）企業(yè)內(nèi)部產(chǎn)品項目，如本企業(yè)內(nèi)部自研自營系統(tǒng)及平臺；

（2）企業(yè)承接電信體系內(nèi)項目，如某單位的故障預處理系統(tǒng)；

（3）企業(yè)承接電信體系外項目，如政企項目。

隨著軟件系統(tǒng)架構復雜度的增加、項目規(guī)模、交付成果和交付環(huán)境要求差異逐漸擴大, 規(guī)范化和標準化的構建和交付流程往往成為影響產(chǎn)品成敗的重要因素。如何在滿足研發(fā)管理規(guī)范的前提下解決這一問題，成為企業(yè)亟待解決的關鍵。

2 相關工作

近年來，微服務、容器技術以及各種自動化運維工具的發(fā)展，大大推動了DevOps 的研究、實踐和應用，業(yè)界諸多企業(yè)及學者對其進行了廣泛研究和應用。文獻[1-2]關注DevOps 在國內(nèi)的發(fā)展中，得出如Docker、Jenkins 等60 多個自動化工具帶來的實際影響以及其帶來經(jīng)驗和問題。在文獻[3]中探討了持續(xù)集成/持續(xù)交付過程可視化的結(jié)果，可以大大提升信息共享的效率和效果；文獻[4]提出了通過可視化方法，對敏捷團隊中各成員的貢獻進行統(tǒng)計和呈現(xiàn)。

綜上文獻調(diào)研結(jié)果與思考，本文提出一種基于DevOps 的流水線可視化自由編排方案，來解決企業(yè)實踐中遇到的問題。

3 方案設計

3.1 流水線可視化自由編排

針對固化的CICD 流水線導致DevOps 執(zhí)行困難或失敗情況，本文創(chuàng)新性的引入流水線“可視化”+“自由編排”任務的方法來解決。在前端視圖中，組織級管理角色擁有權限可對任意任務，如更新代碼、單元測試、靜態(tài)代碼掃描等進行靈活的排序。故，針對某一項目實際情況，可制作出不同的CICD 流水線模板以供使用。

3.1.1 步驟1.流水線原子任務模型定義

通過組織級調(diào)研，分析研發(fā)過程涉及的系統(tǒng)和工具，分解并抽象出系統(tǒng)原子任務，并且提取這些任務在不同項目中特異性的配置作為任務的參數(shù)，如更新代碼任務的分支配置、部署任務的環(huán)境選擇和配置等，部署任務應提供多種環(huán)境供用戶參考選擇，如開發(fā)環(huán)境、測試環(huán)境、預發(fā)布環(huán)境、生產(chǎn)環(huán)境。

其中原子任務包括兩大類，固有任務指流水線階段初始配置中固定存在的任務，包括準備任務、更新代碼、單元測試、靜態(tài)代碼掃描、編譯打包、構建鏡像、部署、晉級、自動化測試、發(fā)布；通用任務指流水線階段初始配置中可自由選擇的任務，包括郵件通知、人工審批、自定義腳本。

3.1.2 步驟2.流水線階段模型定義

圖1：總體技術方案流程

分析出項目或產(chǎn)品研發(fā)過程中的所有活動，并設計出流水線階段，流水線階段一般根據(jù)軟件所處環(huán)境和涉及人員角色來進行劃分。流水線階段中包含流水線階段名稱、固有流水線任務、通用任務的配置，值得一提的是，流水線階段名稱可以與原子任務重名，以明確顯示該階段的作用。如流水線階段名稱為更新代碼，可為其配置更新代碼固有任務，以及郵件通知、人工審批等一種或多種通用任務。如此配置，在項目流水線初始化中，使得流水線階段具備自由選擇通用任務的能力。

3.1.3 步驟3.可視化自由編排流水線模板模型

流水線模板的制定，簡化了流水線初始化流程。具體來說，流水線模板中包括模板名稱、流水線階段和流水線階段順序的定義，基于此可提供一種流水線模板可視化自由編排能力。在前端視圖中，通過添加流水線階段的操作，可添加步驟2 里定義的流水線階段，通過刪除流水線階段操作，可去除步驟2 中定義的流水線階段，兩者結(jié)合可實現(xiàn)流水線階段順序的自由編排。

通過此方法，可自由編排適合各類項目或產(chǎn)品的CICD 流水線模板，以供流水線初始化時選擇使用，完美解決了固化的CICD 流水線使用不佳的體驗。

3.1.4 步驟4.流水線初始化

流水線初始化時，重點研究論述流水線初始化中，流水線模板的選擇以及配置。

假設流水線模板選取代碼檢測模板，選擇更新代碼階段時，可指定更新代碼這個固有任務的分支；同時，亦可添加一種或多種通用任務，并配置通用任務的參數(shù)信息，如添加郵件通知任務，添加郵件通知地址，或企業(yè)微信、短信賬號等；亦可配置通知方式，如執(zhí)行成功/失敗時進行通知。因某一流水線階段下可能含多種任務，為方便調(diào)整這些任務順序，前端視圖具備拖動改變?nèi)蝿請?zhí)行順序功能，通過此舉，實現(xiàn)了在流水線初始化時期，流水線任務的可視化自由編排。

需要指出，已創(chuàng)建的流水線原子任務信息、流水線階段信息、流水線模板皆存儲于Mysql 數(shù)據(jù)庫中。

3.2 流水線可視化監(jiān)控

針對在CICD 流水線執(zhí)行過程中，如何建立可視化的流水線監(jiān)控功能，方便開發(fā)運維人員對問題的及時定位與解決，本文提出以下方案：

后臺服務程序通過定時任務調(diào)用JenkinsAPI，一方面同步流水線狀態(tài)，另一方面獲取運行中流水線日志，經(jīng)服務程序處理后，將運行狀態(tài)與運行時間等信息通過Websocket 返回前端顯示；日志存在ES 數(shù)據(jù)庫，狀態(tài)，時間等信息存在MySQL 中流水線記錄表中?；诖?，可實現(xiàn)如下流水線監(jiān)控內(nèi)容：

（1）流水線的最新執(zhí)行狀態(tài)；

（2） 流水線最近的執(zhí)行信息：流水線實時日志、階段日志、任務日志、流水線狀態(tài)、任務執(zhí)行狀態(tài)；

（3）展示或下載執(zhí)行任務產(chǎn)生的報告或制品；

綜上所述，流水線監(jiān)控可貫穿流水線構建每一個階段。

3.3 總體技術架構與流程

為形成完整的方案架構，需選擇實用的運維工具，本文選擇Git 作為版本控制；Sonar 作為代碼掃描工具；Katalon、JMeter 等作為自動化測試工具；Jenkins 作為集成部署工具等（不包含全部工具）。

本文技術方案流程大致如圖1 所示。

后臺服務程序作為整合各類資源的核心中樞，負責連接前端、Jenkins 服務器、制品庫與數(shù)據(jù)庫服務器，其主要任務有接收前端請求、調(diào)用JenkinsAPI、響應結(jié)果的處理、執(zhí)行定時任務（獲取運行中流水線日志、同步流水線狀態(tài)等）、更新與獲取數(shù)據(jù)庫信息、執(zhí)行制品下載任務等。

數(shù)據(jù)服務器A（MySQL）存儲組織級研發(fā)管理角色創(chuàng)建的流水線任務、階段和模板信息；項目或產(chǎn)品團隊根據(jù)自身項目需求，在前端選取合適的流水線模板并進行流水線配置，初始化流水線后，后臺服務程序一方面將配置信息存儲在數(shù)據(jù)服務器A 流水線配置表中，另一方面服務程序以配置信息為基礎，調(diào)用JenkinsAPI，在Jenkins 服務器中創(chuàng)建持續(xù)集成或持續(xù)部署流水線；當開發(fā)人員通過提交業(yè)務代碼/合并代碼，或在前端手動啟動流水線操作，均可觸發(fā)流水線構建；構建記錄同步于數(shù)據(jù)服務器A 的流水線記錄表中，運行中日志信息同步于前端流水線詳情頁中，運行結(jié)束日志存儲于數(shù)據(jù)服務器B（ES 數(shù)據(jù)庫）中，以供查看歷史構建記錄以及實現(xiàn)流水監(jiān)控；流水線任務構建中產(chǎn)生的War 包、Docker 鏡像等制品，經(jīng)Jenkins 服務器推送到制品庫中，通過后臺服務器處理，可在前端展示或下載。

4 企業(yè)實踐

根據(jù)第3 節(jié)的研究，可對引言中三類項目的困境實施以下方案：

4.1 自營產(chǎn)品A

根據(jù)本方案，設計出自營產(chǎn)品A 的持續(xù)集成流水線：開始-》更新代碼-》單元測試-》代碼檢測-》編譯打包-》構建鏡像-》開發(fā)環(huán)境部署-》制品晉級-》測試環(huán)境部署-》自動化測試-》結(jié)束；設計出自營產(chǎn)品A 的持續(xù)部署流水線：開始-》更新代碼-》制品晉級-》預發(fā)布環(huán)境部署-》自動化測試-》制品晉級-》生產(chǎn)環(huán)境部署-》結(jié)束。

軟件產(chǎn)品A 的團隊通過使用上述配置的持續(xù)集成流水線可以對每次的代碼提交進行測試、集成、上傳制品以及開發(fā)、測試環(huán)境部署驗證，及早集成并發(fā)現(xiàn)代碼階段問題，降低產(chǎn)品集成和發(fā)布的風險。

大規(guī)模應用基于流水線的精益平臺，項目生產(chǎn)率從4.037 人時/功能點提高3.99 人時/功能點，每輪迭代可實現(xiàn)的功能點數(shù)從78.474 提高到80.984。項目生產(chǎn)率的模型公式是：6.39 - 0.0529*開發(fā)人員技能水平 - 0.0188*sprint 開發(fā)規(guī)模（功能點）- 0.951 *需求一次接收率。通過蒙特卡洛模擬和假設檢驗，將迭代規(guī)模從78.474提高到80.984，能夠滿足項目生產(chǎn)率的要求。

通過此方案的實施，幫助企業(yè)順利取得CMMI 成熟度5 級資質(zhì)，并通過信通院首批《DevOps能力成熟度模型標準八》的工具評估（持續(xù)集成、流水線）兩項優(yōu)秀級。

4.2 智能預處理系統(tǒng)B

電信體系內(nèi)項目，在打通本企業(yè)與客戶企業(yè)之間的網(wǎng)絡后，按照客戶要求，需選擇不同的部署環(huán)境，開發(fā)環(huán)境是部署在本企業(yè)開發(fā)環(huán)境上，測試和生產(chǎn)環(huán)境部署在客戶機的生產(chǎn)環(huán)境上。具體流水線可參考企業(yè)內(nèi)部自營項目的選擇，需要注意的是，在配置部署任務時，按照客戶需求來指定部署環(huán)境。

通過本文提出的方案，項目集成頻率從一周一次縮短到一天一次，發(fā)布頻率從一月一次縮短到一周一次，發(fā)布成功率從75%提高到100%。

2019年12月，智能預處理項目B 順利通過了由中國信息通信研究院（簡稱信通院）開展的《研發(fā)運營一體化（ DevOps ）能力成熟度模型》持續(xù)交付部分3 級評估。

4.3 某政企項目C

電信體系外項目，因某政企項目C 網(wǎng)絡需要隔離，無法直接將制品部署到生產(chǎn)環(huán)境，這種情況下，需要配置一條不包含部署階段的流水線，通過平臺構建后，將構建生成的制品通過安全合規(guī)的方式，部署到政企內(nèi)部的生產(chǎn)環(huán)境上。

通過該方案，交付的代碼質(zhì)量和開發(fā)效率得到了顯著提高，交付質(zhì)量得到了提高，提升了客戶滿意度。

5 總結(jié)

企業(yè)實踐證明，采用本文方案既滿足了不同形態(tài)產(chǎn)品的交付要求，又提高了交付效率，保障了交付質(zhì)量。此外，為進一步提升產(chǎn)品下若干條流水線的自由編排能力，解決微服務構架項目中構建與部署流水線難以自動化執(zhí)行問題，產(chǎn)品流水線編排設計將是本團隊下一步的研究重點。