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

居彬 王啟威 謝承翰

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

1 引言

某電信企業承接多種類型產品和項目的開發運維工作，具體歸納有如下幾點：

（1）企業內部產品項目，如本企業內部自研自營系統及平臺；

（2）企業承接電信體系內項目，如某單位的故障預處理系統；

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

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

2 相關工作

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

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

3 方案設計

3.1 流水線可視化自由編排

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

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

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

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

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

圖1：總體技術方案流程

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

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

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

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

3.1.4 步驟4.流水線初始化

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

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

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

3.2 流水線可視化監控

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

后臺服務程序通過定時任務調用JenkinsAPI，一方面同步流水線狀態，另一方面獲取運行中流水線日志，經服務程序處理后，將運行狀態與運行時間等信息通過Websocket 返回前端顯示；日志存在ES 數據庫，狀態，時間等信息存在MySQL 中流水線記錄表中。基于此，可實現如下流水線監控內容：

（1）流水線的最新執行狀態；

（2） 流水線最近的執行信息：流水線實時日志、階段日志、任務日志、流水線狀態、任務執行狀態；

（3）展示或下載執行任務產生的報告或制品；

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

3.3 總體技術架構與流程

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

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

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

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

4 企業實踐

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

4.1 自營產品A

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

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

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

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

4.2 智能預處理系統B

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

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

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

4.3 某政企項目C

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

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

5 總結

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