基於Jenkins打造符合DevOps能力成熟度三級標準的持續整合流水線

JFrog傑蛙科技發表於2020-02-14

DevOps的核心是自動化,自動化的核心是標準化。而DevOps最重要的一環節是持續交付,持續交付中建設的重點是流水線,所以如何打造標準的持續交付流水線則為DevOps建設中最重要的一環,也是評估DevOps能力的一個重要的打分點。

本文內容參照《研發運營一體化(DevOps)能力成熟度模型 第3部分:持續交付》,基於jenkins,對持續整合流水線建設的一些關鍵點進行技術應答,帶領大家把方法論落地到具體的技術點上。

 

文中涉及到的幾個名詞解釋:

1,  流水線:pipeline, 一個應用程式從構建、部署、測試和釋出這個過程實現自動化

2,  製品:構建過程的輸出物,包括軟體包、測試報告、應用配置檔案等。

3,  製品庫:儲存全語言製品的倉庫,提供依賴解析及檔案儲存能力。

4,  後設資料:軟體生命週期全過程資料,如需求id、程式碼提交資訊、構建環境、靜態掃描結果、測試透過率、安全掃描結果等。

 

文章中涉及到的一些技術詳解:見文章《打造企業級pipeline服務的1 8 個疑問》

 

下面,我們來看一下持續整合流水線建設中的配置管理、構建與持續整合、測試管理、部署與釋出管理、環境管理、資料管理、度量與反饋的七個維度的三級標準是如何定義的,並且哪些指標需要在jenkins流水線中體現,如何使用jenkins流水線達到此標準。

 

一,  配置管理


三級標準

Jenkins流水線落地建議方案

版本控制

版本控制系統

1)將配置檔案、構建和部署等自動化指令碼納入版本控制系統管理。
2)有健全的版本控制系統管理機制,包括:程式碼庫命名規範備份與可用性保障機制許可權模型專人專崗管理。

流水線內容(Jenkinsfile)需要納入版本管理
流水線的命名需要有明確規範
流水線應明確許可權,開發人員應只有可讀許可權,模版由專門團隊編寫
技術點:可使用jenkins的Share library特性,由專門團隊在原始碼倉庫中統一管理流水線,

分支管理

短週期分支分支頻繁地向主幹合併

非流水線內容

製品管理

1)將依賴元件納入製品庫管理
2)將所有交付製品納入製品庫管理,比如:測試報告
3)製品庫讀寫有清晰的許可權管控制度

建設統一製品庫,如Artifactory。設定完整的許可權。
收集構建流水線過程中的所有工具的結果資料,並將此類資料定義成後設資料,與製品繫結。如需求、程式碼提交資訊、構建環境資訊、依賴資訊、靜態掃描資訊、單元測試資訊、安全掃描資訊等。
技術點:可採用商用製品庫、如Artifactory。也可自行開發後設資料管理系統,收集構建中過程資料。

單一可信資料來源

版本控制系統和製品庫作為單一可信資料來源,覆蓋生產部署環節

建立統一製品庫,在jenkinsfile中指明製品庫地址,構建時不使用pom檔案中的依賴解析地址,而由其他方式修改依賴解析倉庫到唯一可信倉庫中
技術點:使用Artifactory統一管理製品庫,保證唯一可信源

變更管理

變更過程

1)所有配置項變更由變更管理系統觸發
2)針對每次變更內容進行評審,並使用自動化手段

不涉及流水線、注意配置與應用分離、及配置中心管理

變更追溯

實現版本控制系統和變更管理系統的自動化關聯,資訊雙向同步和實時可追溯

不涉及流水線

變更回滾

1)實現變更管理系統和版本控制系統的同步回滾,保證狀態的一致性
2)回滾操作實現自動化

不涉及流水線,

 

二,  構建與持續整合


三級標準

Jenkins流水線落地建議方案

構建實踐

構建方式

1)定義結構化構建指令碼,實現模組級共享複用
2)構建指令碼由專人專崗統一維護

技術點:使用Jenkins ShareLibrary實現構建模組化管理,並實現全域性共享

構建環境

1)構建環境配置實現標準化
2)有獨立的構建資源池

打造少量固定的標準化構建節點作為獨立的構建資源池,並用k8s叢集建立動態構建節點作為動態資源池。
技術點:jenkins主從架構、jenkins on k8s

構建計劃

1)實現定期自動執行構建和程式碼提交觸發構建
2)明確定義構建計劃和規則,並在研發團隊內共享

技術點:jenkins觸發器,可實現定時構建、輪詢原始碼構建或webhook觸發構建

構建職責

構建工具和環境由專門團隊維護並細分團隊人員職責

jenkins主從節點或構建映象由統一團隊維護。業務部門只使用,不能修改。

持續整合

整合服務

組建專門的持續整合團隊,負責最佳化持續整合系統和服務

統一團隊構建流水線模版與持續整合環境,供開發人員選擇
技術點:可以透過jenkins on k8s方式,打造多種構建環境映象,開發人員提交構建任務時定義所需環境。

整合頻率

研發人員至少每天向程式碼主幹整合一次

不涉及流水線

整合方式

每次程式碼提交觸發自動化構建,構建問題通自動分析精準推送相關人員處理

每次提交程式碼觸發jenkins進行構建,並在構建過程中執行完整的靜態掃描、單元測試等步驟
技術點:jenkins的觸發器功能,可以設定輪訓scm或git的webhook觸發

反饋週期

整合問題反饋和解決可以在幾個小時內完成

jenkins pipeline中要通知構建工作完成或失敗狀態,發郵件或webhook給運維團隊和業務團隊

 

三,  測試管理


三級標準

Jenkins流水線落地建議方案

測試分層策略

分層方法

1)採用程式碼級測試對模組的函式或類方法進行覆蓋全面的單元測試;
2)系統全面的進行效能、容量、穩定性、可靠性、易用性、相容性、安全性等非功能性測試

在流水線中進行單元測試,收集單元測試透過率作為後設資料與製品繫結。

分層策略

1)測試設計以對介面/服務級測試為主,兼顧使用者/業務級測試輔以少量的程式碼級測試
2)對非功能性測試進行全面系統的設計

在流水線中可以整合介面測試,並收集介面測試透過率作為後設資料與製品繫結。

測試時機

1)測試在持續交付過程中的介入時間提前到開發的編碼階段
2)程式碼級測試在模組的函式或類方法開發完成後進行

提高單元測試覆蓋率。

程式碼質量管理

質量規約

1)建立組織級程式碼質量規約
2)建立完整的質量規約,將安全漏洞檢查、合規檢查納入規約
3)建立強制執行的質量門禁體系
4)建立規約固定更新機制

需要在jenkins流水線中增加安全掃描步驟,並對掃描測試結果設定質量關卡。
技術點:Xray作為安全掃描工具整合在流水線中、透過製品後設資料作為質量門禁判斷構建產物是否達標

檢查方式

程式碼質量檢查完全自動化,不需要手工干預

流水線整合sonar掃描工具,每次程式碼提交自動觸發構建、自動化進行原始碼掃描,並將代買壞味道數量、程式碼重複率等結果資料以後設資料方式回寫製品庫。
技術點:sonarqube 程式碼靜態掃描

反饋處理

根據程式碼質量檢查結果反饋及時處理,根據質量規約維持一定的技術債

程式碼靜態掃描結果與製品繫結,回寫到製品庫。透過製品攜帶的後設資料是否透過質量門禁,來判斷製品質量。

自動化測試

自動化設計

1)對介面/服務級測試進行自動化設計
2)對程式碼級測試進行自動化設計

jenkins 流水線增加介面測試及服務測試

自動化開發

1)建立統一的自動化測試框架,統一管理自動化測試用例
2)自動化測試指令碼開發採用資料驅動、關鍵字驅動等方法;

不涉及流水線

自動化執行

1)對介面/服務級與程式碼級測試採用自動化測試
2)自動化測試由流水線自動化觸發

在流水線中進行所需測試

自動化分析

對自動化測試結果具備較強的自動判斷能力,誤報少

流水線中收集各項測試結果,作為後設資料與交付物關聯,保障每個製品都能獲取到完整的測試結果。

 

四,  部署與釋出管理


三級標準

Jenkins流水線落地建議方案

部署與釋出模式

部署方式

部署和釋出實現全自動化

部署過程作為流水線的必要步驟
技術點:對接如saltstack、ansible等工具在流水線中部署

部署過程

1)使用相同的過程和工具完成所有環境部署
2)一次部署過程中使用相同的構建產物

為確保釋出內容為測試過的內容,要實現一次構建多次部署。透過後設資料與倉庫名標識製品成熟度。流水線中要將製品在不同成熟度倉庫移動,並收集各個環境中的結果資料作為後設資料儲存。
技術點:應用配置分離、Artifactory後設資料及promotion功能

部署策略

1)採用定期部署策略,具備按天進行部署的能力
2)應用和環境整體作為部署的最小單位
3)應用和配置進行分離

不涉及流水線

部署質量

1)部署失敗率低
2)部署活動整合自動化測試功能,並以測試結果為部署前置條件
3)每次部署活動提供變更範圍報告和測試報告

部署後會在流水線中進行簡單驗證,收集驗證結果資料。測試結果收集到後設資料中,部署時驗證後設資料,判斷是否透過質量門禁,來實現部署。                  技術點:Artifactory後設資料

 

持續部署流水線

協作模式

透過定義完整的軟體交付過程和清晰的交付規範,保證團隊之間交付的有序

標準化工具鏈及持續整合流水線,收集個階段結果資料作為後設資料,用後設資料標識製品的質量標準,供各個團隊間進行使用。

流水線過程

軟體交付過程中的各個環節建立自動化能力以提升處理效率

不涉及流水線

過程視覺化

1)交付過程在團隊內部可見,資訊在團隊間共享
2)交付狀態可追溯

流水線中收集整個構建過程結果資料,與製品繫結,供所有團隊檢視。
技術點:Artifactory後設資料

 

五,  環境管理


三級標準

Jenkins流水線落地建議方案

環境管理

環境型別

建立標準的研發環境

不涉及流水線

環境構建

1)環境的構建透過自服務的資源交付平臺來完成
2)環境準備時間小時級

可在流水線中自動建立所需環境。
技術點:使用k8s的helm自動拉起整套環境,helm是最佳的實現方式

環境依賴於配置管理

以應用為中心,有服務級依賴的配置管理能力,比如:依賴的關聯服務,資料庫服務、快取服務、關聯應用服務等等

不涉及流水線

 

六,  資料管理


三級標準

Jenkins流水線落地建議方案

測試資料管理

資料來源

匯出部分生產環境資料並清洗敏感資訊後形成基準的測試資料集

不涉及流水線

資料覆蓋

建立體系化測試資料,進行資料依賴管理,覆蓋全部測試分層策略要求的測試型別

不涉及流水線

資料獨立性

1)每個測試用例擁有專屬的測試資料有明確的測試初始狀態
2)測試用例的執行不依賴其他測試用例執行所產生的資料

不涉及流水線

資料變更管理

變更過程

將資料變更納入持續部署流水線,經人工確認後自動完成

流水線與審批系統整合。

相容回滾

每次資料變更同時提供明確的回滾機制,並實現進行變更測試,如:提供升級和回滾兩個自動化指令碼

不涉及流水線

資料監控

針對不同環境和危險程度對資料變更建立分級監控機制

不涉及流水線

 

七,  度量與反饋


三級標準

Jenkins流水線落地建議方案

度量指標

度量指標定義

建立跨組織度量指標,進行跨領域綜合維度的度量

不涉及流水線

度量指標型別

度量指標覆蓋過程指標,客觀反映組織研發現狀

流水線中需要收集後設資料,作為後續度量指標

度量資料管理

持續收集度量資料歷史度量資料有明確的管理規則

流水線中需要收集後設資料,作為後續度量指標

度量指標更新

1)度量指標可以按照需求定期更新
2)度量指標的優先順序在團隊內部達成一致

不涉及流水線

度量驅動改進

內容和生成方式

度量報告進行分類分級並按需生成內容

流水線中需要收集後設資料,作為後續度量指標。對後設資料進行二次清晰,生成報告

資料時效性

透過視覺化看板實時展示資料

看板需要展示流水線狀態,如構建時間、透過率、故障率等

覆蓋範圍

全部團隊成員均可檢視報告

不涉及流水線

反饋改進

度量反饋問題納入研發迭代的待辦事項列表,作為持續改進的一部分

不涉及流水線

 

透過上述資料及分析,可以看出,打造出一個標準的流水線服務可以匹配到 60% 的三級標準。那麼我們可以在整個DevOps的建設中投入較大的力量來打造流水線。一套標準的流水線服務和穩定的工具鏈將會成為DevOps建設的一個基石,並且成為貫穿你的整個建設週期中。


學習更多技術知識可以關注我們的線上課堂

關注微信公眾號:JFrog傑蛙DevOps, 獲取課程通知


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69954434/viewspace-2675634/,如需轉載,請註明出處,否則將追究法律責任。

相關文章