基於Jenkins打造符合DevOps能力成熟度三級標準的持續整合流水線
DevOps的核心是自動化,自動化的核心是標準化。而DevOps最重要的一環節是持續交付,持續交付中建設的重點是流水線,所以如何打造標準的持續交付流水線則為DevOps建設中最重要的一環,也是評估DevOps能力的一個重要的打分點。
本文內容參照《研發運營一體化(DevOps)能力成熟度模型 第3部分:持續交付》,基於jenkins,對持續整合流水線建設的一些關鍵點進行技術應答,帶領大家把方法論落地到具體的技術點上。
文中涉及到的幾個名詞解釋:
1, 流水線:pipeline, 一個應用程式從構建、部署、測試和釋出這個過程實現自動化
2, 製品:構建過程的輸出物,包括軟體包、測試報告、應用配置檔案等。
3, 製品庫:儲存全語言製品的倉庫,提供依賴解析及檔案儲存能力。
4, 後設資料:軟體生命週期全過程資料,如需求id、程式碼提交資訊、構建環境、靜態掃描結果、測試透過率、安全掃描結果等。
文章中涉及到的一些技術詳解:見文章《打造企業級pipeline服務的1 8 個疑問》
下面,我們來看一下持續整合流水線建設中的配置管理、構建與持續整合、測試管理、部署與釋出管理、環境管理、資料管理、度量與反饋的七個維度的三級標準是如何定義的,並且哪些指標需要在jenkins流水線中體現,如何使用jenkins流水線達到此標準。
一, 配置管理
|
三級標準 |
Jenkins流水線落地建議方案 | |
版本控制 |
版本控制系統 |
1)將配置檔案、構建和部署等自動化指令碼納入版本控制系統管理。
|
流水線內容(Jenkinsfile)需要納入版本管理
|
分支管理 |
短週期分支分支頻繁地向主幹合併 |
非流水線內容 | |
製品管理 |
1)將依賴元件納入製品庫管理
|
建設統一製品庫,如Artifactory。設定完整的許可權。
| |
單一可信資料來源 |
版本控制系統和製品庫作為單一可信資料來源,覆蓋生產部署環節 |
建立統一製品庫,在jenkinsfile中指明製品庫地址,構建時不使用pom檔案中的依賴解析地址,而由其他方式修改依賴解析倉庫到唯一可信倉庫中
| |
變更管理 |
變更過程 |
1)所有配置項變更由變更管理系統觸發
|
不涉及流水線、注意配置與應用分離、及配置中心管理 |
變更追溯 |
實現版本控制系統和變更管理系統的自動化關聯,資訊雙向同步和實時可追溯 |
不涉及流水線 | |
變更回滾 |
1)實現變更管理系統和版本控制系統的同步回滾,保證狀態的一致性
|
不涉及流水線, |
二, 構建與持續整合
|
三級標準 |
Jenkins流水線落地建議方案 | |
構建實踐 |
構建方式 |
1)定義結構化構建指令碼,實現模組級共享複用
|
技術點:使用Jenkins ShareLibrary實現構建模組化管理,並實現全域性共享 |
構建環境 |
1)構建環境配置實現標準化
|
打造少量固定的標準化構建節點作為獨立的構建資源池,並用k8s叢集建立動態構建節點作為動態資源池。
| |
構建計劃 |
1)實現定期自動執行構建和程式碼提交觸發構建
|
技術點:jenkins觸發器,可實現定時構建、輪詢原始碼構建或webhook觸發構建 | |
構建職責 |
構建工具和環境由專門團隊維護並細分團隊人員職責 |
jenkins主從節點或構建映象由統一團隊維護。業務部門只使用,不能修改。 | |
持續整合 |
整合服務 |
組建專門的持續整合團隊,負責最佳化持續整合系統和服務 |
統一團隊構建流水線模版與持續整合環境,供開發人員選擇
|
整合頻率 |
研發人員至少每天向程式碼主幹整合一次 |
不涉及流水線 | |
整合方式 |
每次程式碼提交觸發自動化構建,構建問題通自動分析精準推送相關人員處理 |
每次提交程式碼觸發jenkins進行構建,並在構建過程中執行完整的靜態掃描、單元測試等步驟
| |
反饋週期 |
整合問題反饋和解決可以在幾個小時內完成 |
jenkins pipeline中要通知構建工作完成或失敗狀態,發郵件或webhook給運維團隊和業務團隊 |
三, 測試管理
|
三級標準 |
Jenkins流水線落地建議方案 | |
測試分層策略 |
分層方法 |
1)採用程式碼級測試對模組的函式或類方法進行覆蓋全面的單元測試;
|
在流水線中進行單元測試,收集單元測試透過率作為後設資料與製品繫結。 |
分層策略 |
1)測試設計以對介面/服務級測試為主,兼顧使用者/業務級測試輔以少量的程式碼級測試
|
在流水線中可以整合介面測試,並收集介面測試透過率作為後設資料與製品繫結。 | |
測試時機 |
1)測試在持續交付過程中的介入時間提前到開發的編碼階段
|
提高單元測試覆蓋率。 | |
程式碼質量管理 |
質量規約 |
1)建立組織級程式碼質量規約
|
需要在jenkins流水線中增加安全掃描步驟,並對掃描測試結果設定質量關卡。
|
檢查方式 |
程式碼質量檢查完全自動化,不需要手工干預 |
流水線整合sonar掃描工具,每次程式碼提交自動觸發構建、自動化進行原始碼掃描,並將代買壞味道數量、程式碼重複率等結果資料以後設資料方式回寫製品庫。
| |
反饋處理 |
根據程式碼質量檢查結果反饋及時處理,根據質量規約維持一定的技術債 |
程式碼靜態掃描結果與製品繫結,回寫到製品庫。透過製品攜帶的後設資料是否透過質量門禁,來判斷製品質量。 | |
自動化測試 |
自動化設計 |
1)對介面/服務級測試進行自動化設計
|
jenkins 流水線增加介面測試及服務測試 |
自動化開發 |
1)建立統一的自動化測試框架,統一管理自動化測試用例
|
不涉及流水線 | |
自動化執行 |
1)對介面/服務級與程式碼級測試採用自動化測試
|
在流水線中進行所需測試 | |
自動化分析 |
對自動化測試結果具備較強的自動判斷能力,誤報少 |
流水線中收集各項測試結果,作為後設資料與交付物關聯,保障每個製品都能獲取到完整的測試結果。 |
四, 部署與釋出管理
|
三級標準 |
Jenkins流水線落地建議方案 | |
部署與釋出模式 |
部署方式 |
部署和釋出實現全自動化 |
部署過程作為流水線的必要步驟
|
部署過程 |
1)使用相同的過程和工具完成所有環境部署
|
為確保釋出內容為測試過的內容,要實現一次構建多次部署。透過後設資料與倉庫名標識製品成熟度。流水線中要將製品在不同成熟度倉庫移動,並收集各個環境中的結果資料作為後設資料儲存。
| |
部署策略 |
1)採用定期部署策略,具備按天進行部署的能力
|
不涉及流水線 | |
部署質量 |
1)部署失敗率低
|
部署後會在流水線中進行簡單驗證,收集驗證結果資料。測試結果收集到後設資料中,部署時驗證後設資料,判斷是否透過質量門禁,來實現部署。 技術點:Artifactory後設資料
| |
持續部署流水線 |
協作模式 |
透過定義完整的軟體交付過程和清晰的交付規範,保證團隊之間交付的有序 |
標準化工具鏈及持續整合流水線,收集個階段結果資料作為後設資料,用後設資料標識製品的質量標準,供各個團隊間進行使用。 |
流水線過程 |
軟體交付過程中的各個環節建立自動化能力以提升處理效率 |
不涉及流水線 | |
過程視覺化 |
1)交付過程在團隊內部可見,資訊在團隊間共享
|
流水線中收集整個構建過程結果資料,與製品繫結,供所有團隊檢視。
|
五, 環境管理
|
三級標準 |
Jenkins流水線落地建議方案 | |
環境管理 |
環境型別 |
建立標準的研發環境 |
不涉及流水線 |
環境構建 |
1)環境的構建透過自服務的資源交付平臺來完成
|
可在流水線中自動建立所需環境。
| |
環境依賴於配置管理 |
以應用為中心,有服務級依賴的配置管理能力,比如:依賴的關聯服務,資料庫服務、快取服務、關聯應用服務等等 |
不涉及流水線 |
六, 資料管理
|
三級標準 |
Jenkins流水線落地建議方案 | |
測試資料管理 |
資料來源 |
匯出部分生產環境資料並清洗敏感資訊後形成基準的測試資料集 |
不涉及流水線 |
資料覆蓋 |
建立體系化測試資料,進行資料依賴管理,覆蓋全部測試分層策略要求的測試型別 |
不涉及流水線 | |
資料獨立性 |
1)每個測試用例擁有專屬的測試資料有明確的測試初始狀態
|
不涉及流水線 | |
資料變更管理 |
變更過程 |
將資料變更納入持續部署流水線,經人工確認後自動完成 |
流水線與審批系統整合。 |
相容回滾 |
每次資料變更同時提供明確的回滾機制,並實現進行變更測試,如:提供升級和回滾兩個自動化指令碼 |
不涉及流水線 | |
資料監控 |
針對不同環境和危險程度對資料變更建立分級監控機制 |
不涉及流水線 |
七, 度量與反饋
|
三級標準 |
Jenkins流水線落地建議方案 | |
度量指標 |
度量指標定義 |
建立跨組織度量指標,進行跨領域綜合維度的度量 |
不涉及流水線 |
度量指標型別 |
度量指標覆蓋過程指標,客觀反映組織研發現狀 |
流水線中需要收集後設資料,作為後續度量指標 | |
度量資料管理 |
持續收集度量資料歷史度量資料有明確的管理規則 |
流水線中需要收集後設資料,作為後續度量指標 | |
度量指標更新 |
1)度量指標可以按照需求定期更新
|
不涉及流水線 | |
度量驅動改進 |
內容和生成方式 |
度量報告進行分類分級並按需生成內容 |
流水線中需要收集後設資料,作為後續度量指標。對後設資料進行二次清晰,生成報告 |
資料時效性 |
透過視覺化看板實時展示資料 |
看板需要展示流水線狀態,如構建時間、透過率、故障率等 | |
覆蓋範圍 |
全部團隊成員均可檢視報告 |
不涉及流水線 | |
反饋改進 |
度量反饋問題納入研發迭代的待辦事項列表,作為持續改進的一部分 |
不涉及流水線 |
透過上述資料及分析,可以看出,打造出一個標準的流水線服務可以匹配到 60% 的三級標準。那麼我們可以在整個DevOps的建設中投入較大的力量來打造流水線。一套標準的流水線服務和穩定的工具鏈將會成為DevOps建設的一個基石,並且成為貫穿你的整個建設週期中。
學習更多技術知識可以關注我們的線上課堂
關注微信公眾號:JFrog傑蛙DevOps, 獲取課程通知
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69954434/viewspace-2675634/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Jenkins持續整合Jenkins
- 使用流水線外掛實現持續整合、持續部署
- 企業DevOps之路:Jenkins 流水線devJenkins
- Jenkins持續整合配置Jenkins
- 持續整合工具之Jenkins基礎使用Jenkins
- CODING 敏捷實戰系列課第四講:從頭搭建持續整合 DevOps 流水線敏捷dev
- Azure DevOps(一)基於 Net6.0 的 WPF 程式如何進行持續整合、持續編譯dev編譯
- 持續整合 Jenkins 簡介Jenkins
- jenkins+docker 持續整合JenkinsDocker
- 持續整合Jenkins+GitlabJenkinsGitlab
- Jenkins 持續整合使用教程Jenkins
- 用於持續整合的13種Jenkins替代方案 -DEVJenkinsdev
- Jenkins教程:使用Jenkins進行持續整合Jenkins
- 如何將 InfoSec、Compliance 整合到持續交付流水線中
- Linux下搭建Jenkins持續整合LinuxJenkins
- 基於K8s構建Jenkins持續整合平臺(部署流程)K8SJenkins
- 基於Kubernetes/K8S構建Jenkins持續整合平臺(下)K8SJenkins
- 「持續整合實踐系列 」Jenkins 2.x 構建CI自動化流水線常見技巧Jenkins
- 騰訊WeTest參與DevOps能力成熟度模型國家標準研討會dev模型
- 【DevOps進行時】持續交付廣義流水線探索 - 農行DevOps實踐之路 | LEANSOFTdev
- RF+Jenkins構建持續整合Jenkins
- Jenkins持續整合 入門實踐Jenkins
- 基於Kubernetes/K8S構建Jenkins持續整合平臺(上)-1K8SJenkins
- 基於Kubernetes/K8S構建Jenkins持續整合平臺(上)-2K8SJenkins
- docker版jenkins持續整合部署及連線gitee碼雲DockerJenkinsGitee
- Ansible 持續整合Anolis、Ubuntu基線配置Ubuntu
- 標準解讀:零信任能力成熟度模型模型
- 自動化專案Jenkins持續整合Jenkins
- 持續整合工具之Jenkins安裝部署Jenkins
- 手摸手聊聊小程式持續整合JenkinsJenkins
- jenkins介面、UI自動化持續整合JenkinsUI
- 基於Jenkins + Argo 實現多叢集的持續交付JenkinsGo
- 基於開發者中心DevOps流水線快速上雲dev
- 前端專案基於GitLab-CI的持續整合/持續部署(CI/CD)前端Gitlab
- 使用 Jenkins 建立微服務應用的持續整合Jenkins微服務
- SpringBoot+Docker+Git+Jenkins實現簡易的持續整合和持續部署Spring BootDockerGitJenkins
- gitlab和jenkins做持續整合構建教程GitlabJenkins
- Framework專案持續整合(jenkins)及集合SonarQubeFrameworkJenkins