您好,登錄后才能下訂單哦!
基于Jenkins如何打造符合DevOps能力成熟度三級標準的持續(xù)集成流水線,相信很多沒有經(jīng)驗的人對此束手無策,為此本文總結(jié)了問題出現(xiàn)的原因和解決方法,通過這篇文章希望你能解決這個問題。
DevOps的核心是自動化,自動化的核心是標準化。而DevOps最重要的一環(huán)節(jié)是持續(xù)交付,持續(xù)交付中建設(shè)的重點是流水線,所以如何打造標準的持續(xù)交付流水線則為DevOps建設(shè)中最重要的一環(huán),也是評估DevOps能力的一個重要的打分點。
基于jenkins,對持續(xù)集成流水線建設(shè)的一些關(guān)鍵點進行技術(shù)應(yīng)答,帶領(lǐng)大家把方法論落地到具體的技術(shù)點上。
文中涉及到的幾個名詞解釋:
1, 流水線:pipeline,一個應(yīng)用程序從構(gòu)建、部署、測試和發(fā)布這個過程實現(xiàn)自動化
2, 制品:構(gòu)建過程的輸出物,包括軟件包、測試報告、應(yīng)用配置文件等。
3, 制品庫:存儲全語言制品的倉庫,提供依賴解析及文件存儲能力。
4, 元數(shù)據(jù):軟件生命周期全過程數(shù)據(jù),如需求id、代碼提交信息、構(gòu)建環(huán)境、靜態(tài)掃描結(jié)果、測試通過率、安全掃描結(jié)果等。
文章中涉及到的一些技術(shù)詳解:見文章《打造企業(yè)級pipeline服務(wù)的18個疑問》
下面,我們來看一下持續(xù)集成流水線建設(shè)中的配置管理、構(gòu)建與持續(xù)集成、測試管理、部署與發(fā)布管理、環(huán)境管理、數(shù)據(jù)管理、度量與反饋的七個維度的三級標準是如何定義的,并且哪些指標需要在jenkins流水線中體現(xiàn),如何使用jenkins流水線達到此標準。
一, 配置管理
三級標準 | Jenkins流水線落地建議方案 | ||
版本控制 | 版本控制系統(tǒng) | 1)將配置文件、構(gòu)建和部署等自動化腳本納入版本控制系統(tǒng)管理。2)有健全的版本控制系統(tǒng)管理機制,包括:代碼庫命名規(guī)范備份與可用性保障機制權(quán)限模型專人專崗管理。 | 流水線內(nèi)容(Jenkinsfile)需要納入版本管理流水線的命名需要有明確規(guī)范流水線應(yīng)明確權(quán)限,開發(fā)人員應(yīng)只有可讀權(quán)限,模版由專門團隊編寫技術(shù)點:可使用jenkins的Share library特性,由專門團隊在源碼倉庫中統(tǒng)一管理流水線, |
分支管理 | 短周期分支分支頻繁地向主干合并 | 非流水線內(nèi)容 | |
制品管理 | 1)將依賴組件納入制品庫管理2)將所有交付制品納入制品庫管理,比如:測試報告3)制品庫讀寫有清晰的權(quán)限管控制度 | 建設(shè)統(tǒng)一制品庫,如Artifactory。設(shè)置完整的權(quán)限。收集構(gòu)建流水線過程中的所有工具的結(jié)果數(shù)據(jù),并將此類數(shù)據(jù)定義成元數(shù)據(jù),與制品綁定。如需求、代碼提交信息、構(gòu)建環(huán)境信息、依賴信息、靜態(tài)掃描信息、單元測試信息、安全掃描信息等。技術(shù)點:可采用商用制品庫、如Artifactory。也可自行開發(fā)元數(shù)據(jù)管理系統(tǒng),收集構(gòu)建中過程數(shù)據(jù)。 | |
單一可信數(shù)據(jù)源 | 版本控制系統(tǒng)和制品庫作為單一可信數(shù)據(jù)源,覆蓋生產(chǎn)部署環(huán)節(jié) | 建立統(tǒng)一制品庫,在jenkinsfile中指明制品庫地址,構(gòu)建時不使用pom文件中的依賴解析地址,而由其他方式修改依賴解析倉庫到唯一可信倉庫中技術(shù)點:使用Artifactory統(tǒng)一管理制品庫,保證唯一可信源 | |
變更管理 | 變更過程 | 1)所有配置項變更由變更管理系統(tǒng)觸發(fā)2)針對每次變更內(nèi)容進行評審,并使用自動化手段 | 不涉及流水線、注意配置與應(yīng)用分離、及配置中心管理 |
變更追溯 | 實現(xiàn)版本控制系統(tǒng)和變更管理系統(tǒng)的自動化關(guān)聯(lián),信息雙向同步和實時可追溯 | 不涉及流水線 | |
變更回滾 | 1)實現(xiàn)變更管理系統(tǒng)和版本控制系統(tǒng)的同步回滾,保證狀態(tài)的一致性2)回滾操作實現(xiàn)自動化 | 不涉及流水線, |
二, 構(gòu)建與持續(xù)集成
三級標準 | Jenkins流水線落地建議方案 | ||
構(gòu)建實踐 | 構(gòu)建方式 | 1)定義結(jié)構(gòu)化構(gòu)建腳本,實現(xiàn)模塊級共享復(fù)用2)構(gòu)建腳本由專人專崗統(tǒng)一維護 | 技術(shù)點:使用Jenkins ShareLibrary實現(xiàn)構(gòu)建模塊化管理,并實現(xiàn)全局共享 |
構(gòu)建環(huán)境 | 1)構(gòu)建環(huán)境配置實現(xiàn)標準化2)有獨立的構(gòu)建資源池 | 打造少量固定的標準化構(gòu)建節(jié)點作為獨立的構(gòu)建資源池,并用k8s集群創(chuàng)建動態(tài)構(gòu)建節(jié)點作為動態(tài)資源池。技術(shù)點:jenkins主從架構(gòu)、jenkins on k8s | |
構(gòu)建計劃 | 1)實現(xiàn)定期自動執(zhí)行構(gòu)建和代碼提交觸發(fā)構(gòu)建2)明確定義構(gòu)建計劃和規(guī)則,并在研發(fā)團隊內(nèi)共享 | 技術(shù)點:jenkins觸發(fā)器,可實現(xiàn)定時構(gòu)建、輪詢源碼構(gòu)建或webhook觸發(fā)構(gòu)建 | |
構(gòu)建職責 | 構(gòu)建工具和環(huán)境由專門團隊維護并細分團隊人員職責 | jenkins主從節(jié)點或構(gòu)建鏡像由統(tǒng)一團隊維護。業(yè)務(wù)部門只使用,不能修改。 | |
持續(xù)集成 | 集成服務(wù) | 組建專門的持續(xù)集成團隊,負責優(yōu)化持續(xù)集成系統(tǒng)和服務(wù) | 統(tǒng)一團隊構(gòu)建流水線模版與持續(xù)集成環(huán)境,供開發(fā)人員選擇技術(shù)點:可以通過jenkins on k8s方式,打造多種構(gòu)建環(huán)境鏡像,開發(fā)人員提交構(gòu)建任務(wù)時定義所需環(huán)境。 |
集成頻率 | 研發(fā)人員至少每天向代碼主干集成一次 | 不涉及流水線 | |
集成方式 | 每次代碼提交觸發(fā)自動化構(gòu)建,構(gòu)建問題通自動分析精準推送相關(guān)人員處理 | 每次提交代碼觸發(fā)jenkins進行構(gòu)建,并在構(gòu)建過程中執(zhí)行完整的靜態(tài)掃描、單元測試等步驟技術(shù)點:jenkins的觸發(fā)器功能,可以設(shè)置輪訓(xùn)scm或git的webhook觸發(fā) | |
反饋周期 | 集成問題反饋和解決可以在幾個小時內(nèi)完成 | jenkins pipeline中要通知構(gòu)建工作完成或失敗狀態(tài),發(fā)郵件或webhook給運維團隊和業(yè)務(wù)團隊 |
三, 測試管理
三級標準 | Jenkins流水線落地建議方案 | ||
測試分層策略 | 分層方法 | 1)采用代碼級測試對模塊的函數(shù)或類方法進行覆蓋全面的單元測試;2)系統(tǒng)全面的進行性能、容量、穩(wěn)定性、可靠性、易用性、兼容性、安全性等非功能性測試 | 在流水線中進行單元測試,收集單元測試通過率作為元數(shù)據(jù)與制品綁定。 |
分層策略 | 1)測試設(shè)計以對接口/服務(wù)級測試為主,兼顧用戶/業(yè)務(wù)級測試輔以少量的代碼級測試2)對非功能性測試進行全面系統(tǒng)的設(shè)計 | 在流水線中可以集成接口測試,并收集接口測試通過率作為元數(shù)據(jù)與制品綁定。 | |
測試時機 | 1)測試在持續(xù)交付過程中的介入時間提前到開發(fā)的編碼階段2)代碼級測試在模塊的函數(shù)或類方法開發(fā)完成后進行 | 提高單元測試覆蓋率。 | |
代碼質(zhì)量管理 | 質(zhì)量規(guī)約 | 1)建立組織級代碼質(zhì)量規(guī)約2)建立完整的質(zhì)量規(guī)約,將安全漏洞檢查、合規(guī)檢查納入規(guī)約3)建立強制執(zhí)行的質(zhì)量門禁體系4)建立規(guī)約固定更新機制 | 需要在jenkins流水線中增加安全掃描步驟,并對掃描測試結(jié)果設(shè)置質(zhì)量關(guān)卡。技術(shù)點:Xray作為安全掃描工具集成在流水線中、通過制品元數(shù)據(jù)作為質(zhì)量門禁判斷構(gòu)建產(chǎn)物是否達標 |
檢查方式 | 代碼質(zhì)量檢查完全自動化,不需要手工干預(yù) | 流水線集成sonar掃描工具,每次代碼提交自動觸發(fā)構(gòu)建、自動化進行源碼掃描,并將代買壞味道數(shù)量、代碼重復(fù)率等結(jié)果數(shù)據(jù)以元數(shù)據(jù)方式回寫制品庫。技術(shù)點:sonarqube代碼靜態(tài)掃描 | |
反饋處理 | 根據(jù)代碼質(zhì)量檢查結(jié)果反饋及時處理,根據(jù)質(zhì)量規(guī)約維持一定的技術(shù)債 | 代碼靜態(tài)掃描結(jié)果與制品綁定,回寫到制品庫。通過制品攜帶的元數(shù)據(jù)是否通過質(zhì)量門禁,來判斷制品質(zhì)量。 | |
自動化測試 | 自動化設(shè)計 | 1)對接口/服務(wù)級測試進行自動化設(shè)計2)對代碼級測試進行自動化設(shè)計 | jenkins 流水線增加接口測試及服務(wù)測試 |
自動化開發(fā) | 1)建立統(tǒng)一的自動化測試框架,統(tǒng)一管理自動化測試用例2)自動化測試腳本開發(fā)采用數(shù)據(jù)驅(qū)動、關(guān)鍵字驅(qū)動等方法; | 不涉及流水線 | |
自動化執(zhí)行 | 1)對接口/服務(wù)級與代碼級測試采用自動化測試2)自動化測試由流水線自動化觸發(fā) | 在流水線中進行所需測試 | |
自動化分析 | 對自動化測試結(jié)果具備較強的自動判斷能力,誤報少 | 流水線中收集各項測試結(jié)果,作為元數(shù)據(jù)與交付物關(guān)聯(lián),保障每個制品都能獲取到完整的測試結(jié)果。 |
四, 部署與發(fā)布管理
三級標準 | Jenkins流水線落地建議方案 | ||
部署與發(fā)布模式 | 部署方式 | 部署和發(fā)布實現(xiàn)全自動化 | 部署過程作為流水線的必要步驟技術(shù)點:對接如saltstack、ansible等工具在流水線中部署 |
部署過程 | 1)使用相同的過程和工具完成所有環(huán)境部署2)一次部署過程中使用相同的構(gòu)建產(chǎn)物 | 為確保發(fā)布內(nèi)容為測試過的內(nèi)容,要實現(xiàn)一次構(gòu)建多次部署。通過元數(shù)據(jù)與倉庫名標識制品成熟度。流水線中要將制品在不同成熟度倉庫移動,并收集各個環(huán)境中的結(jié)果數(shù)據(jù)作為元數(shù)據(jù)存儲。技術(shù)點:應(yīng)用配置分離、Artifactory元數(shù)據(jù)及promotion功能 | |
部署策略 | 1)采用定期部署策略,具備按天進行部署的能力2)應(yīng)用和環(huán)境整體作為部署的最小單位3)應(yīng)用和配置進行分離 | 不涉及流水線 | |
部署質(zhì)量 | 1)部署失敗率低2)部署活動集成自動化測試功能,并以測試結(jié)果為部署前置條件3)每次部署活動提供變更范圍報告和測試報告 | 部署后會在流水線中進行簡單驗證,收集驗證結(jié)果數(shù)據(jù)。測試結(jié)果收集到元數(shù)據(jù)中,部署時驗證元數(shù)據(jù),判斷是否通過質(zhì)量門禁,來實現(xiàn)部署。 技術(shù)點:Artifactory元數(shù)據(jù) | |
持續(xù)部署流水線 | 協(xié)作模式 | 通過定義完整的軟件交付過程和清晰的交付規(guī)范,保證團隊之間交付的有序 | 標準化工具鏈及持續(xù)集成流水線,收集個階段結(jié)果數(shù)據(jù)作為元數(shù)據(jù),用元數(shù)據(jù)標識制品的質(zhì)量標準,供各個團隊間進行使用。 |
流水線過程 | 軟件交付過程中的各個環(huán)節(jié)建立自動化能力以提升處理效率 | 不涉及流水線 | |
過程可視化 | 1)交付過程在團隊內(nèi)部可見,信息在團隊間共享2)交付狀態(tài)可追溯 | 流水線中收集整個構(gòu)建過程結(jié)果數(shù)據(jù),與制品綁定,供所有團隊查看。技術(shù)點:Artifactory元數(shù)據(jù) |
五, 環(huán)境管理
三級標準 | Jenkins流水線落地建議方案 | ||
環(huán)境管理 | 環(huán)境類型 | 建立標準的研發(fā)環(huán)境 | 不涉及流水線 |
環(huán)境構(gòu)建 | 1)環(huán)境的構(gòu)建通過自服務(wù)的資源交付平臺來完成2)環(huán)境準備時間小時級 | 可在流水線中自動創(chuàng)建所需環(huán)境。技術(shù)點:使用k8s的helm自動拉起整套環(huán)境,helm是最佳的實現(xiàn)方式 | |
環(huán)境依賴于配置管理 | 以應(yīng)用為中心,有服務(wù)級依賴的配置管理能力,比如:依賴的關(guān)聯(lián)服務(wù),數(shù)據(jù)庫服務(wù)、緩存服務(wù)、關(guān)聯(lián)應(yīng)用服務(wù)等等 | 不涉及流水線 |
六, 數(shù)據(jù)管理
三級標準 | Jenkins流水線落地建議方案 | ||
測試數(shù)據(jù)管理 | 數(shù)據(jù)來源 | 導(dǎo)出部分生產(chǎn)環(huán)境數(shù)據(jù)并清洗敏感信息后形成基準的測試數(shù)據(jù)集 | 不涉及流水線 |
數(shù)據(jù)覆蓋 | 建立體系化測試數(shù)據(jù),進行數(shù)據(jù)依賴管理,覆蓋全部測試分層策略要求的測試類型 | 不涉及流水線 | |
數(shù)據(jù)獨立性 | 1)每個測試用例擁有專屬的測試數(shù)據(jù)有明確的測試初始狀態(tài)2)測試用例的執(zhí)行不依賴其他測試用例執(zhí)行所產(chǎn)生的數(shù)據(jù) | 不涉及流水線 | |
數(shù)據(jù)變更管理 | 變更過程 | 將數(shù)據(jù)變更納入持續(xù)部署流水線,經(jīng)人工確認后自動完成 | 流水線與審批系統(tǒng)集成。 |
兼容回滾 | 每次數(shù)據(jù)變更同時提供明確的回滾機制,并實現(xiàn)進行變更測試,如:提供升級和回滾兩個自動化腳本 | 不涉及流水線 | |
數(shù)據(jù)監(jiān)控 | 針對不同環(huán)境和危險程度對數(shù)據(jù)變更建立分級監(jiān)控機制 | 不涉及流水線 |
七, 度量與反饋
三級標準 | Jenkins流水線落地建議方案 | ||
度量指標 | 度量指標定義 | 建立跨組織度量指標,進行跨領(lǐng)域綜合維度的度量 | 不涉及流水線 |
度量指標類型 | 度量指標覆蓋過程指標,客觀反映組織研發(fā)現(xiàn)狀 | 流水線中需要收集元數(shù)據(jù),作為后續(xù)度量指標 | |
度量數(shù)據(jù)管理 | 持續(xù)收集度量數(shù)據(jù)歷史度量數(shù)據(jù)有明確的管理規(guī)則 | 流水線中需要收集元數(shù)據(jù),作為后續(xù)度量指標 | |
度量指標更新 | 1)度量指標可以按照需求定期更新2)度量指標的優(yōu)先級在團隊內(nèi)部達成一致 | 不涉及流水線 | |
度量驅(qū)動改進 | 內(nèi)容和生成方式 | 度量報告進行分類分級并按需生成內(nèi)容 | 流水線中需要收集元數(shù)據(jù),作為后續(xù)度量指標。對元數(shù)據(jù)進行二次清晰,生成報告 |
數(shù)據(jù)時效性 | 通過可視化看板實時展示數(shù)據(jù) | 看板需要展示流水線狀態(tài),如構(gòu)建時間、通過率、故障率等 | |
覆蓋范圍 | 全部團隊成員均可查看報告 | 不涉及流水線 | |
反饋改進 | 度量反饋問題納入研發(fā)迭代的待辦事項列表,作為持續(xù)改進的一部分 | 不涉及流水線 |
通過上述數(shù)據(jù)及分析,可以看出,打造出一個標準的流水線服務(wù)可以匹配到60%的三級標準。那么我們可以在整個DevOps的建設(shè)中投入較大的力量來打造流水線。一套標準的流水線服務(wù)和穩(wěn)定的工具鏈將會成為DevOps建設(shè)的一個基石,并且成為貫穿你的整個建設(shè)周期中。
看完上述內(nèi)容,你們掌握基于Jenkins如何打造符合DevOps能力成熟度三級標準的持續(xù)集成流水線的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。