戰(zhàn)：測(cè)試策略動(dòng)態(tài)切換，CI耗時(shí)從45分鐘降到8分鐘)
聊個(gè)實(shí)戰(zhàn)項(xiàng)目。前陣子我被開(kāi)發(fā)同事問(wèn)得最多的一句話是“CI怎么又排隊(duì)了” 不是Jenkins機(jī)器不夠而是測(cè)試用例堆到一定量級(jí)之后每次合并分支都全量跑測(cè)試一跑就是四十多分鐘十個(gè)人的小團(tuán)隊(duì)光等構(gòu)建就耗掉大量時(shí)間。我當(dāng)時(shí)的想法很簡(jiǎn)單能不能讓Jenkins Pipeline根據(jù)“這次改動(dòng)到底影響什么”來(lái)自動(dòng)決定跑哪些測(cè)試這就是“測(cè)試策略動(dòng)態(tài)切換”的由來(lái)。這套方案做下來(lái)效果立竿見(jiàn)影日常分支提交的平均測(cè)試時(shí)間從40多分鐘降到8分鐘左右合并到主干前才跑完整回歸而且漏測(cè)風(fēng)險(xiǎn)并沒(méi)有明顯上升。如果你也在維護(hù)Jenkins Pipeline、被“全量測(cè)試跑不完”的問(wèn)題困擾或者剛接觸Pipeline想看看成熟的策略設(shè)計(jì)長(zhǎng)什么樣這篇內(nèi)容應(yīng)該能幫你省不少?gòu)澛?。我下面?huì)拆解設(shè)計(jì)思路、關(guān)鍵參數(shù)、Jenkinsfile核心實(shí)現(xiàn)以及我踩過(guò)的幾個(gè)坑。1. 項(xiàng)目背景與方案選型1.1 團(tuán)隊(duì)遇到的真實(shí)痛點(diǎn)先說(shuō)背景。我們的項(xiàng)目是Spring Cloud微服務(wù)架構(gòu)前端兩個(gè)倉(cāng)庫(kù)、后端六個(gè)倉(cāng)庫(kù)共用一套Jenkins。測(cè)試用例分為三層單元測(cè)試、接口測(cè)試基于RestAssured、端到端測(cè)試基于Selenium。最瘋狂的時(shí)候一次全量回歸的用例數(shù)接近四千條穩(wěn)定耗時(shí)在45到55分鐘之間。這個(gè)耗時(shí)帶來(lái)的問(wèn)題很直接開(kāi)發(fā)每次提交MRCI排隊(duì)時(shí)間越來(lái)越長(zhǎng)反饋周期從“下樓倒杯水”變成“吃頓午飯”。測(cè)試用例的執(zhí)行結(jié)果集中在最后幾分鐘才出來(lái)開(kāi)發(fā)發(fā)現(xiàn)問(wèn)題時(shí)上下文已經(jīng)切換了好幾輪。QA同學(xué)想單獨(dú)觸發(fā)某個(gè)模塊的接口測(cè)試要么手動(dòng)挑用例要么改Jenkins任務(wù)配置操作成本高且容易出錯(cuò)。我統(tǒng)計(jì)過(guò)一周的構(gòu)建數(shù)據(jù)真正需要全量回歸的場(chǎng)景其實(shí)只有兩類合并到master發(fā)版前、每晚定時(shí)巡檢。日常的feature分支和develop合并大多只影響兩三個(gè)服務(wù)模塊。但在當(dāng)時(shí)的CI配置里所有觸發(fā)都走同一條全量流水線完全沒(méi)有區(qū)分度。這個(gè)痛點(diǎn)的本質(zhì)是CI的執(zhí)行成本和變更風(fēng)險(xiǎn)不匹配。全量跑安全但浪費(fèi)不跑高效但危險(xiǎn)。動(dòng)態(tài)切換要解決的就是在兩者之間找到一個(gè)按需分配的執(zhí)行策略。1.2 方案對(duì)比為什么繼續(xù)用Jenkins Pipeline當(dāng)時(shí)也考慮過(guò)其他方案。GitLab CI在倉(cāng)庫(kù)里寫(xiě).gitlab-ci.yml和代碼同倉(cāng)庫(kù)管理很直觀但我們的Jenkins上已經(jīng)有一套權(quán)限體系、憑據(jù)管理、Agent節(jié)點(diǎn)池和構(gòu)建歷史遷移成本太高。GitHub Actions對(duì)私有倉(cāng)庫(kù)的并發(fā)數(shù)和計(jì)費(fèi)方式在當(dāng)時(shí)也不合適。自研一個(gè)測(cè)試分發(fā)Runner更不現(xiàn)實(shí)光Agent管理就夠喝一壺。所以結(jié)論是繼續(xù)用Jenkins但要把原來(lái)的“自由風(fēng)格項(xiàng)目”升級(jí)成Pipeline。為什么Pipeline適合做這件事自由風(fēng)格項(xiàng)目是圖形化配置邏輯分散在界面里一旦要加條件判斷、參數(shù)傳遞、動(dòng)態(tài)選擇測(cè)試范圍UI配置會(huì)變得極其別扭。而Pipeline本質(zhì)上是把構(gòu)建流程寫(xiě)成代碼Jenkinsfile存入代碼倉(cāng)庫(kù)具備版本管理能力。這意味著我可以在Jenkinsfile里寫(xiě)Groovy腳本來(lái)動(dòng)態(tài)計(jì)算測(cè)試策略也可以把策略邏輯抽成共享庫(kù)供多個(gè)倉(cāng)庫(kù)復(fù)用。這里我特別想強(qiáng)調(diào)一個(gè)選型心得不要為了“動(dòng)態(tài)”而把所有邏輯都寫(xiě)進(jìn)Groovy。Pipeline的script塊雖然支持任意Groovy代碼但濫用會(huì)讓Jenkinsfile變成一坨難以維護(hù)的意大利面。我的做法是Jenkinsfile只保留流程骨架策略計(jì)算邏輯單獨(dú)抽成Groovy方法必要時(shí)下沉到共享庫(kù)。這樣主流程清晰策略邏輯也能單獨(dú)測(cè)試。2. 核心設(shè)計(jì)測(cè)試策略路由2.1 定了哪幾檔策略動(dòng)態(tài)切換不是說(shuō)“每次跑什么完全隨機(jī)”而是事先定義好幾檔標(biāo)準(zhǔn)策略再根據(jù)觸發(fā)條件自動(dòng)選擇其中一檔。我最終定義了四檔第一檔冒煙測(cè)試Smoke。適用于任意分支的push觸發(fā)只跑核心鏈路用例確保服務(wù)能啟、主流程能通總耗時(shí)控制在3到5分鐘。第二檔受影響模塊測(cè)試Module。適用于feature分支提交MR時(shí)通過(guò)分析本次變更涉及的服務(wù)模塊動(dòng)態(tài)匹配關(guān)聯(lián)的接口測(cè)試和單元測(cè)試。第三檔全量回歸Full。適用于合并到master、打tag、發(fā)版前以及每晚定時(shí)任務(wù)完整跑全量用例確保發(fā)布安全。第四檔手動(dòng)指定Manual。適用于QA或開(kāi)發(fā)手動(dòng)點(diǎn)擊構(gòu)建時(shí)通過(guò)Jenkins參數(shù)選擇要執(zhí)行的模塊和測(cè)試類型這個(gè)作為兜底方案靈活度最高。為什么是四檔而不是更多我見(jiàn)過(guò)有人把測(cè)試策略細(xì)分成十幾檔結(jié)果維護(hù)成本太高最后大家都在手動(dòng)選參數(shù)。四檔覆蓋了日常開(kāi)發(fā)的主流程和特殊場(chǎng)景既保留自動(dòng)化判斷的空間又留有人工介入的口子屬于比較健康的復(fù)雜度。需要特別說(shuō)明的是檔位之間不是互斥關(guān)系。比如主分支的自動(dòng)構(gòu)建觸發(fā)了冒煙測(cè)試但同一分支上如果有手動(dòng)觸發(fā)的全量回歸參數(shù)策略計(jì)算會(huì)優(yōu)先采用手動(dòng)參數(shù)。這個(gè)優(yōu)先級(jí)邏輯在后面會(huì)具體講。2.2 四個(gè)核心參數(shù)怎么設(shè)計(jì)策略路由的本質(zhì)是參數(shù)驅(qū)動(dòng)。我在Jenkinsfile頂部定義了四個(gè)核心參數(shù)貫穿整條Pipeline參數(shù)名類型默認(rèn)值用途RUN_MODE選擇框AUTO自動(dòng)策略 / 手動(dòng)指定策略TEST_LEVEL選擇框SMOKE測(cè)試檔位SMOKE / MODULE / FULLMODULE_LIST字符串空當(dāng)檔位為MODULE時(shí)指定要測(cè)試的模塊列表逗號(hào)分隔IS_NIGHTLY布爾值false是否為定時(shí)觸發(fā)的夜間全量回歸在Jenkins Pipeline里parameters塊配置好這些參數(shù)后無(wú)論手動(dòng)構(gòu)建還是API觸發(fā)都可以覆蓋。這里的經(jīng)驗(yàn)點(diǎn)是參數(shù)要夠用但不要泛濫。早期我加了TEST_LEVEL之外還加過(guò)SKIP_UNIT、SKIP_API、RETRY_COUNT等等結(jié)果開(kāi)發(fā)同事根本不知道參數(shù)怎么選反而更依賴手動(dòng)觸發(fā)默認(rèn)行為。后來(lái)收斂成這四個(gè)參數(shù)每個(gè)參數(shù)都有明確的使用場(chǎng)景上手成本就低很多了。其中MODULE_LIST可以說(shuō)是最關(guān)鍵的一個(gè)參數(shù)。因?yàn)槟K名需要和代碼目錄、測(cè)試目錄的命名強(qiáng)一致我設(shè)計(jì)了一個(gè)約定后端服務(wù)模塊的命名統(tǒng)一使用service-xxx測(cè)試工程的目錄也按service-xxx組織。這個(gè)約定讓策略計(jì)算可以直接通過(guò)路徑匹配來(lái)反推模塊列表省掉了一張維護(hù)成本很高的映射表。2.3 策略路由的數(shù)據(jù)流理解了參數(shù)之后再看數(shù)據(jù)流就清楚了。整條Pipeline的策略路由分為三個(gè)階段第一階段是“計(jì)算策略”。Pipeline啟動(dòng)后首先進(jìn)入Init階段讀取觸發(fā)方式webhook、定時(shí)還是手動(dòng)、讀取GIT_*環(huán)境變量、讀取用戶填寫(xiě)的參數(shù)然后調(diào)用resolveTestStrategy()方法得到策略結(jié)果。第二階段是“分發(fā)執(zhí)行”。計(jì)算出來(lái)的策略結(jié)果寫(xiě)入一個(gè)Map變量例如[level: MODULE, modules: [service-a, service-b], needFull: false]。后續(xù)的Test階段通過(guò)讀取這個(gè)Map來(lái)決定執(zhí)行哪些測(cè)試任務(wù)而不是在測(cè)試任務(wù)里再重新做一次判斷。第三階段是“匯總反饋”。所有測(cè)試任務(wù)執(zhí)行完后統(tǒng)一收集JUnit報(bào)告計(jì)算通過(guò)率和耗時(shí)再根據(jù)策略信息生成向企業(yè)微信通知推送的內(nèi)容。這里有一個(gè)設(shè)計(jì)要點(diǎn)是策略計(jì)算和策略執(zhí)行必須解耦。我見(jiàn)過(guò)有的Pipeline把判斷邏輯塞進(jìn)每個(gè)stage的when條件里比如when { expression { return params.TEST_LEVEL FULL } }表面看沒(méi)問(wèn)題但一旦判斷條件復(fù)雜了多條件組合會(huì)讓when塊變得非?；逎?。我的做法是先算出一個(gè)“策略對(duì)象”后續(xù)所有節(jié)點(diǎn)都只消費(fèi)這個(gè)對(duì)象邏輯清晰且便于打日志調(diào)試。3. 實(shí)操過(guò)程與關(guān)鍵實(shí)現(xiàn)3.1 Jenkinsfile整體骨架直接看代碼。以下是簡(jiǎn)化后的Jenkinsfile骨架包含了參數(shù)定義、策略計(jì)算和執(zhí)行分發(fā)pipeline { agent { label linux-test } options { timestamps() timeout(time: 2, unit: HOURS) buildDiscarder(logRotator(numToKeepStr: 30)) disableConcurrentBuilds() } parameters { choice(name: RUN_MODE, choices: [AUTO, MANUAL], description: 自動(dòng)策略或手動(dòng)策略) choice(name: TEST_LEVEL, choices: [SMOKE, MODULE, FULL], description: 手動(dòng)指定測(cè)試檔位) string(name: MODULE_LIST, defaultValue: , description: 測(cè)試模塊列表逗號(hào)分隔) booleanParam(name: IS_NIGHTLY, defaultValue: false, description: 是否夜間定時(shí)構(gòu)建) } environment { PROJECT_NAME mall-platform BASE_REF develop TEST_RESULT_DIR ${WORKSPACE}/build/reports } stages { stage(初始化) { steps { script { STRATEGY resolveTestStrategy() echo 當(dāng)前測(cè)試策略: ${STRATEGY} } } } stage(構(gòu)建) { steps { echo 開(kāi)始構(gòu)建服務(wù)... // 實(shí)際構(gòu)建過(guò)程例如 mvn clean package -DskipTests } } stage(測(cè)試) { parallel { stage(單元測(cè)試) { when { expression { return shouldRunUnitTest(STRATEGY) } } steps { script { // 執(zhí)行選中模塊的單測(cè) } } post { always { junit testResults: **/target/surefire-reports/*.xml, allowEmptyResults: true } } } stage(接口測(cè)試) { when { expression { return shouldRunApiTest(STRATEGY) } } steps { script { // 執(zhí)行選中模塊的接口測(cè)試 } } post { always { junit testResults: **/target/failsafe-reports/*.xml, allowEmptyResults: true } } } stage(端到端測(cè)試) { when { expression { return STRATEGY.level FULL } } steps { script { // 執(zhí)行E2E測(cè)試 } } post { always { junit testResults: **/build/reports/e2e/*.xml, allowEmptyResults: true } } } } } stage(通知) { steps { script { notifyWechat(STRATEGY) } } } } }骨架里的STRATEGY變量是全局的在頂層通過(guò)def STRATEGY null聲明然后在初始化階段用script塊賦值。這利用了Groovy腳本在Jenkins Pipeline中的全局變量傳遞機(jī)制。3.2 策略計(jì)算邏輯怎么寫(xiě)策略計(jì)算的核心方法是resolveTestStrategy()。它的輸入是參數(shù)、分支名、變更文件列表輸出是一個(gè)Map。def resolveTestStrategy() { def branch env.GIT_BRANCH ?: env.BRANCH_NAME def level SMOKE def modules [] def needFull false // 手動(dòng)策略優(yōu)先 if (params.RUN_MODE MANUAL params.TEST_LEVEL ! SMOKE) { level params.TEST_LEVEL if (params.MODULE_LIST?.trim()) { modules params.MODULE_LIST.split(,).collect { it.trim() } } if (level FULL) { needFull true } return [level: level, modules: modules, needFull: needFull] } // 夜間定時(shí)構(gòu)建直接全量 if (params.IS_NIGHTLY) { return [level: FULL, modules: [], needFull: true] } // 主干分支策略master 和 release 分支合并前全量 if (branch master || branch release) { return [level: FULL, modules: [], needFull: true] } // 非主干分支先看變更文件列表再?zèng)Q定是冒煙還是模塊測(cè)試 def changeFiles getChangedFiles() if (changeFiles.isEmpty()) { return [level: SMOKE, modules: [], needFull: false] } def affectedModules parseModulesFromChangeFiles(changeFiles) if (affectedModules.size() 4) { // 改動(dòng)的模塊太多說(shuō)明是大范圍變更退回全量更安全 return [level: FULL, modules: [], needFull: true] } if (affectedModules.size() 0) { return [level: MODULE, modules: affectedModules, needFull: false] } return [level: SMOKE, modules: [], needFull: false] }這里面有兩個(gè)輔助方法值得單獨(dú)說(shuō)。getChangedFiles()的實(shí)現(xiàn)依賴Jenkins的changeSets。在多分支Pipeline里可以在script塊中直接讀取當(dāng)前構(gòu)建的變更集例如def getChangedFiles() { def files [] if (currentBuild.changeSets) { currentBuild.changeSets.each { changeSet - changeSet.items.each { item - item.affectedFiles.each { file - files.add(file.path) } } } } return files }這里有個(gè)坑currentBuild.changeSets只有在“分支被重新掃描后觸發(fā)構(gòu)建”的場(chǎng)景下才有值比如MR事件觸發(fā)的構(gòu)建。如果是定時(shí)構(gòu)建的第一次執(zhí)行變更集為空所以策略會(huì)回退到冒煙測(cè)試。這其實(shí)符合預(yù)期——定時(shí)構(gòu)建我本來(lái)就設(shè)置了IS_NIGHTLY參數(shù)來(lái)指定全量。parseModulesFromChangeFiles()的思路就是根據(jù)目錄前綴匹配模塊名。例如變更文件是service-order/src/main/java/...那么模塊名就是service-order。如果變更文件是common-utils/src/main/java/...那么模塊名歸入common-utils但這屬于公共模塊我會(huì)在匹配時(shí)把它忽略因?yàn)楣材K變更需要走全量。這個(gè)邏輯看似簡(jiǎn)單但有一點(diǎn)特別重要當(dāng)公共模塊被大量改動(dòng)時(shí)只跑關(guān)聯(lián)模塊是不夠的。所以我在策略里加了個(gè)閾值規(guī)則——當(dāng)受影響模塊數(shù)大于等于4個(gè)時(shí)升級(jí)為FULL策略。這個(gè)閾值是從兩次線上事故中總結(jié)出來(lái)的第一次公共模塊改動(dòng)只跑了兩個(gè)服務(wù)的接口測(cè)試結(jié)果牽連到第三個(gè)服務(wù)第二次是前端依賴升級(jí)后端模塊列表解析出來(lái)只有3個(gè)但數(shù)據(jù)庫(kù)連接池的公共配置被改了直接回歸暴露了配置錯(cuò)誤。定成4是折中的結(jié)果你們可以根據(jù)自己服務(wù)數(shù)量的三分之一量級(jí)來(lái)調(diào)整。3.3 各stage怎么消費(fèi)策略策略計(jì)算完了后面每個(gè)stage都需要消費(fèi)策略結(jié)果。消費(fèi)方式有兩種我在項(xiàng)目里都用到了。第一種是when條件判斷。比如端到端測(cè)試只有在STRATEGY.level FULL時(shí)才執(zhí)行單元測(cè)試和接口測(cè)試在策略為SMOKE或MODULE時(shí)也可能會(huì)執(zhí)行。具體判斷邏輯我封裝成了shouldRunUnitTest()這樣的方法def shouldRunUnitTest(Map strategy) { if (strategy.level FULL || strategy.level MODULE) { return true } if (params.RUN_MODE MANUAL params.TEST_LEVEL SMOKE) { return true } return false }第二種是動(dòng)態(tài)拼接測(cè)試命令。在接口測(cè)試stage里策略計(jì)算出的modules列表要轉(zhuǎn)成Maven或Gradle的命令行參數(shù)if [ ${STRATEGY.modules.size()} -gt 0 ]; then MODULES_PARAM$(echo ${STRATEGY.modules.join(,)} | tr , ) echo 本次接口測(cè)試模塊: ${MODULES_PARAM} # 實(shí)際執(zhí)行例如 # mvn test -pl $MODULES_PARAM -DtestApiTestSuite else echo 策略未指定模塊跳過(guò)接口測(cè)試 exit 0 fi這段邏輯放在script { sh ... }里通過(guò)Groovy的字符串拼接把策略信息傳給shell腳本。有一個(gè)細(xì)節(jié)Groovy里的List變量在傳給sh時(shí)不能直接當(dāng)作shell數(shù)組使用必須先在Groovy里拼成字符串再接進(jìn)shell腳本否則容易出現(xiàn)org.jenkinsci.plugins.scriptsecurity.sandbox相關(guān)的序列化異常。3.4 測(cè)試結(jié)果匯總與通知測(cè)試跑完結(jié)果不能白跑。我每次構(gòu)建結(jié)束都會(huì)做三件事收集JUnit報(bào)告、提取測(cè)試摘要、推送企業(yè)微信通知。JUnit報(bào)告收集在Jenkins Pipeline里就是junit方法注意要設(shè)置allowEmptyResults: true。如果不設(shè)置某個(gè)stage因?yàn)椴呗蕴^(guò)了導(dǎo)致沒(méi)有生成XML報(bào)告Pipeline會(huì)直接報(bào)錯(cuò)No test reports found。這個(gè)參數(shù)很多剛用Pipeline的人容易漏我剛開(kāi)始也在這上面卡了兩次。測(cè)試摘要可以通過(guò)currentBuild.testSummary這類插件提供的能力來(lái)獲取。比如在always塊里把測(cè)試總數(shù)、失敗數(shù)、跳過(guò)數(shù)寫(xiě)進(jìn)環(huán)境變量然后傳給通知腳本post { always { script { def summary currentBuild.testSummary ?: 無(wú)測(cè)試摘要 env.TEST_SUMMARY summary } } }企業(yè)微信通知我用的是httpRequest插件調(diào)用Webhook機(jī)器人接口。通知內(nèi)容里我會(huì)特意帶上策略信息和主要模塊列表【CI通知】mall-platform #123 構(gòu)建成功 分支feature/order-v2 測(cè)試策略MODULE (service-order, service-payment) 測(cè)試結(jié)果通過(guò) 128失敗 2已關(guān)聯(lián)到缺陷單 耗時(shí)12分30秒 構(gòu)建地址${BUILD_URL}為什么強(qiáng)制帶策略信息因?yàn)閳F(tuán)隊(duì)里其他人看到通知時(shí)需要知道“這次為什么只跑了這幾個(gè)模塊”。如果你不帶模塊信息后面出了問(wèn)題開(kāi)發(fā)會(huì)直接來(lái)質(zhì)問(wèn)你為什么漏測(cè)。帶著策略和模塊列表整個(gè)CI過(guò)程就變得可審計(jì)、可追溯了。4. 踩坑記錄與排查技巧4.1 常見(jiàn)問(wèn)題速查表動(dòng)態(tài)切換策略這套方案我前后迭代了四五個(gè)版本踩過(guò)的坑不算少。整理幾個(gè)最典型的供你排查時(shí)參考問(wèn)題現(xiàn)象根本原因解決辦法策略一直是SMOKE模塊測(cè)試從不觸發(fā)currentBuild.changeSets為空獲取變更文件失敗檢查webhook觸發(fā)類型MR事件必須由push事件攜帶變更列表觸發(fā)而不是依賴repository_dispatchJasonfile里執(zhí)行sh mvn test但找不到模塊工作目錄不是倉(cāng)庫(kù)根目錄或Agent上WORKSPACE路徑包含空格統(tǒng)一指定dir(${WORKSPACE}/backend)包裹執(zhí)行并在agent上檢查路徑并發(fā)構(gòu)建相互搶測(cè)試資源多個(gè)feature分支同時(shí)觸發(fā)接口測(cè)試共用同一批服務(wù)端口對(duì)共享測(cè)試環(huán)境加disableConcurrentBuilds()同時(shí)區(qū)分獨(dú)立環(huán)境的Agent標(biāo)簽手動(dòng)參數(shù)不生效系統(tǒng)總是自動(dòng)計(jì)算策略when條件的優(yōu)先級(jí)高于手動(dòng)參數(shù)邏輯參數(shù)還沒(méi)賦值就被過(guò)濾在resolveTestStrategy()里優(yōu)先判斷params.RUN_MODE MANUAL并確保parameters塊在agent之前定義JUnit報(bào)告統(tǒng)計(jì)不準(zhǔn)失敗用例不顯示測(cè)試報(bào)告生成路徑被多級(jí)目錄嵌套junit匹配規(guī)則太寬精確到具體目錄backend/**/target/surefire-reports/*.xml并檢查是否是用了allowEmptyResults掩蓋了路徑錯(cuò)誤定時(shí)構(gòu)建走了FULL策略但郵件通知里沒(méi)有策略信息env.TEST_SUMMARY在sh腳本里被覆蓋Groovy變量作用域沖突使用全局變量STRATEGY作為唯一數(shù)據(jù)源不重復(fù)賦值給環(huán)境變量構(gòu)建卡在策略計(jì)算階段getChangedFiles()在掃描大量文件時(shí)性能很差或Pipeline并發(fā)掃描導(dǎo)致死鎖限制變更文件數(shù)量超過(guò)一定量級(jí)直接返回全量策略4.2 幾個(gè)容易被忽略的細(xì)節(jié)除了上面表格里的問(wèn)題還有幾個(gè)經(jīng)驗(yàn)值得展開(kāi)講。第一個(gè)是Agent標(biāo)簽管理。我的測(cè)試Agent分為兩類linux-build和linux-test。構(gòu)建和測(cè)試分開(kāi)跑避免Maven編譯進(jìn)程搶占測(cè)試進(jìn)程的資源。測(cè)試Agent用restartOrdinarily方式調(diào)度如果該Agent上的測(cè)試服務(wù)版本不對(duì)經(jīng)常出現(xiàn)端口沖突或者污染上一次的測(cè)試環(huán)境。后來(lái)我在構(gòu)建腳本里強(qiáng)行執(zhí)行mvn clean并在每次構(gòu)建前清空${WORKSPACE}/build目錄才把這個(gè)問(wèn)題壓下去。第二條是不要在每個(gè)stage里重復(fù)計(jì)算策略。因?yàn)槲矣龅竭^(guò)這種情況Pipeline前面的STRATEGY變量在stage里被誤改或者并行stage里去訪問(wèn)全局變量時(shí)Groovy沙箱的綁定不一致直接導(dǎo)致NullPointerException。后來(lái)我規(guī)定STRATEGY只能由初始化階段寫(xiě)入后續(xù)所有stage都只讀不允許更新。代碼審查時(shí)這也成了一條規(guī)定。第三條是超時(shí)和重試機(jī)制。測(cè)試任務(wù)掛起是最煩人的。我在options里加了全局timeout同時(shí)在接口測(cè)試stage上還單獨(dú)加了retry(count: 2)。你可能會(huì)問(wèn)全量回歸那么長(zhǎng)超時(shí)設(shè)兩小時(shí)夠不夠我的經(jīng)驗(yàn)是先設(shè)一個(gè)保守時(shí)間跑兩周觀察實(shí)際耗時(shí)再往下調(diào)整。盡量不要一開(kāi)始就設(shè)很緊的超時(shí)否則一個(gè)慢用例就會(huì)讓整個(gè)構(gòu)建莫名其妙失敗。第四條關(guān)于jenkins可用環(huán)境變量。Pipeline里的env有很多變量來(lái)自插件和構(gòu)建配置比如BRANCH_NAME、GIT_COMMIT、CHANGE_TITLE、CHANGE_ID。我一開(kāi)始用GIT_BRANCH判斷分支后來(lái)發(fā)現(xiàn)它和BRANCH_NAME的表現(xiàn)不一樣多分支Pipeline里應(yīng)該優(yōu)先用BRANCH_NAME。這個(gè)小坑不踩一次根本不知道Jenkins的參數(shù)命名這么有“歷史包袱”。5. 這套方案的邊界與后續(xù)擴(kuò)展測(cè)試策略動(dòng)態(tài)切換不是萬(wàn)能的。它的核心假設(shè)是“變更影響范圍可以預(yù)測(cè)”對(duì)于模塊邊界清晰的中型項(xiàng)目這個(gè)假設(shè)成立對(duì)于那種一次提交改動(dòng)幾十個(gè)文件、尤其是公共底層模塊頻繁改動(dòng)的大型單體策略計(jì)算容易失效反復(fù)觸發(fā)全量回歸后反而不如直接把全量跑拆成并行分片來(lái)得實(shí)惠。我目前已經(jīng)在嘗試的后續(xù)擴(kuò)展有兩個(gè)方向。一個(gè)是自動(dòng)失敗用例重跑。全量回歸中偶爾會(huì)有幾個(gè)用例因?yàn)榄h(huán)境抖動(dòng)失敗但并非真實(shí)缺陷。我在策略里新增了“失敗用例自動(dòng)重跑一次仍然失敗才標(biāo)記為真失敗”的邏輯這樣有效減少了人工確認(rèn)的工作量。另一個(gè)方向是結(jié)合AI分析測(cè)試影響。Jenkins已經(jīng)支持AI Agent插件通過(guò)分析代碼變更的調(diào)用鏈和測(cè)試用例之間的關(guān)聯(lián)關(guān)系自動(dòng)生成受影響模塊列表。現(xiàn)在我的parseModulesFromChangeFiles()還是基于目錄約定的靜態(tài)匹配未來(lái)如果能接入AI分析策略的準(zhǔn)確性和精細(xì)度還能再提升一個(gè)臺(tái)階。不過(guò)我要潑一盆冷水動(dòng)態(tài)切換策略這件事真正的難點(diǎn)不在于代碼怎么寫(xiě)而在于團(tuán)隊(duì)是否信任這套策略。要讓開(kāi)發(fā)放心測(cè)試結(jié)果和策略判斷必須透明可查要讓QA放心手動(dòng)指定策略必須始終兜底要讓團(tuán)隊(duì)放心降級(jí)規(guī)則例如公共模塊改動(dòng)量過(guò)大就直接全量必須清晰寫(xiě)在文檔里。CI的本質(zhì)是團(tuán)隊(duì)協(xié)作的潤(rùn)滑劑如果為了省時(shí)間而犧牲了信任那這個(gè)方案走不遠(yuǎn)。我做這套方案最深的感受是Jenkins Pipeline的強(qiáng)大之處從來(lái)不在于語(yǔ)法多花哨而在于它能讓你把“構(gòu)建流程”當(dāng)成一個(gè)真正的軟件工程來(lái)設(shè)計(jì)。參數(shù)、策略、測(cè)試、通知每一層都可以獨(dú)立演進(jìn)穩(wěn)定的底層支撐靈活的頂層。如果你也想在團(tuán)隊(duì)里做類似的事建議從一檔全量、一檔冒煙開(kāi)始跑通之后再加模塊級(jí)測(cè)試一步步把復(fù)雜度控制住。測(cè)試策略動(dòng)態(tài)切換說(shuō)到底不是技術(shù)問(wèn)題而是“如何讓CI更懂業(yè)務(wù)”的問(wèn)題。 Jenkins Pipeline實(shí)戰(zhàn)：測(cè)試策略動(dòng)態(tài)切換，CI耗時(shí)從45分鐘降到8分鐘
聊個(gè)實(shí)戰(zhàn)項(xiàng)目。前陣子我被開(kāi)發(fā)同事問(wèn)得最多的一句話是“CI怎么又排隊(duì)了” 不是Jenkins機(jī)器不夠而是測(cè)試用例堆到一定量級(jí)之后每次合并分支都全量跑測(cè)試一跑就是四十多分鐘十個(gè)人的小團(tuán)隊(duì)光等構(gòu)建就耗掉大量時(shí)間。我當(dāng)時(shí)的想法很簡(jiǎn)單能不能讓Jenkins Pipeline根據(jù)“這次改動(dòng)到底影響什么”來(lái)自動(dòng)決定跑哪些測(cè)試這就是“測(cè)試策略動(dòng)態(tài)切換”的由來(lái)。這套方案做下來(lái)效果立竿見(jiàn)影日常分支提交的平均測(cè)試時(shí)間從40多分鐘降到8分鐘左右合并到主干前才跑完整回歸而且漏測(cè)風(fēng)險(xiǎn)并沒(méi)有明顯上升。如果你也在維護(hù)Jenkins Pipeline、被“全量測(cè)試跑不完”的問(wèn)題困擾或者剛接觸Pipeline想看看成熟的策略設(shè)計(jì)長(zhǎng)什么樣這篇內(nèi)容應(yīng)該能幫你省不少?gòu)澛?。我下面?huì)拆解設(shè)計(jì)思路、關(guān)鍵參數(shù)、Jenkinsfile核心實(shí)現(xiàn)以及我踩過(guò)的幾個(gè)坑。1. 項(xiàng)目背景與方案選型1.1 團(tuán)隊(duì)遇到的真實(shí)痛點(diǎn)先說(shuō)背景。我們的項(xiàng)目是Spring Cloud微服務(wù)架構(gòu)前端兩個(gè)倉(cāng)庫(kù)、后端六個(gè)倉(cāng)庫(kù)共用一套Jenkins。測(cè)試用例分為三層單元測(cè)試、接口測(cè)試基于RestAssured、端到端測(cè)試基于Selenium。最瘋狂的時(shí)候一次全量回歸的用例數(shù)接近四千條穩(wěn)定耗時(shí)在45到55分鐘之間。這個(gè)耗時(shí)帶來(lái)的問(wèn)題很直接開(kāi)發(fā)每次提交MRCI排隊(duì)時(shí)間越來(lái)越長(zhǎng)反饋周期從“下樓倒杯水”變成“吃頓午飯”。測(cè)試用例的執(zhí)行結(jié)果集中在最后幾分鐘才出來(lái)開(kāi)發(fā)發(fā)現(xiàn)問(wèn)題時(shí)上下文已經(jīng)切換了好幾輪。QA同學(xué)想單獨(dú)觸發(fā)某個(gè)模塊的接口測(cè)試要么手動(dòng)挑用例要么改Jenkins任務(wù)配置操作成本高且容易出錯(cuò)。我統(tǒng)計(jì)過(guò)一周的構(gòu)建數(shù)據(jù)真正需要全量回歸的場(chǎng)景其實(shí)只有兩類合并到master發(fā)版前、每晚定時(shí)巡檢。日常的feature分支和develop合并大多只影響兩三個(gè)服務(wù)模塊。但在當(dāng)時(shí)的CI配置里所有觸發(fā)都走同一條全量流水線完全沒(méi)有區(qū)分度。這個(gè)痛點(diǎn)的本質(zhì)是CI的執(zhí)行成本和變更風(fēng)險(xiǎn)不匹配。全量跑安全但浪費(fèi)不跑高效但危險(xiǎn)。動(dòng)態(tài)切換要解決的就是在兩者之間找到一個(gè)按需分配的執(zhí)行策略。1.2 方案對(duì)比為什么繼續(xù)用Jenkins Pipeline當(dāng)時(shí)也考慮過(guò)其他方案。GitLab CI在倉(cāng)庫(kù)里寫(xiě).gitlab-ci.yml和代碼同倉(cāng)庫(kù)管理很直觀但我們的Jenkins上已經(jīng)有一套權(quán)限體系、憑據(jù)管理、Agent節(jié)點(diǎn)池和構(gòu)建歷史遷移成本太高。GitHub Actions對(duì)私有倉(cāng)庫(kù)的并發(fā)數(shù)和計(jì)費(fèi)方式在當(dāng)時(shí)也不合適。自研一個(gè)測(cè)試分發(fā)Runner更不現(xiàn)實(shí)光Agent管理就夠喝一壺。所以結(jié)論是繼續(xù)用Jenkins但要把原來(lái)的“自由風(fēng)格項(xiàng)目”升級(jí)成Pipeline。為什么Pipeline適合做這件事自由風(fēng)格項(xiàng)目是圖形化配置邏輯分散在界面里一旦要加條件判斷、參數(shù)傳遞、動(dòng)態(tài)選擇測(cè)試范圍UI配置會(huì)變得極其別扭。而Pipeline本質(zhì)上是把構(gòu)建流程寫(xiě)成代碼Jenkinsfile存入代碼倉(cāng)庫(kù)具備版本管理能力。這意味著我可以在Jenkinsfile里寫(xiě)Groovy腳本來(lái)動(dòng)態(tài)計(jì)算測(cè)試策略也可以把策略邏輯抽成共享庫(kù)供多個(gè)倉(cāng)庫(kù)復(fù)用。這里我特別想強(qiáng)調(diào)一個(gè)選型心得不要為了“動(dòng)態(tài)”而把所有邏輯都寫(xiě)進(jìn)Groovy。Pipeline的script塊雖然支持任意Groovy代碼但濫用會(huì)讓Jenkinsfile變成一坨難以維護(hù)的意大利面。我的做法是Jenkinsfile只保留流程骨架策略計(jì)算邏輯單獨(dú)抽成Groovy方法必要時(shí)下沉到共享庫(kù)。這樣主流程清晰策略邏輯也能單獨(dú)測(cè)試。2. 核心設(shè)計(jì)測(cè)試策略路由2.1 定了哪幾檔策略動(dòng)態(tài)切換不是說(shuō)“每次跑什么完全隨機(jī)”而是事先定義好幾檔標(biāo)準(zhǔn)策略再根據(jù)觸發(fā)條件自動(dòng)選擇其中一檔。我最終定義了四檔第一檔冒煙測(cè)試Smoke。適用于任意分支的push觸發(fā)只跑核心鏈路用例確保服務(wù)能啟、主流程能通總耗時(shí)控制在3到5分鐘。第二檔受影響模塊測(cè)試Module。適用于feature分支提交MR時(shí)通過(guò)分析本次變更涉及的服務(wù)模塊動(dòng)態(tài)匹配關(guān)聯(lián)的接口測(cè)試和單元測(cè)試。第三檔全量回歸Full。適用于合并到master、打tag、發(fā)版前以及每晚定時(shí)任務(wù)完整跑全量用例確保發(fā)布安全。第四檔手動(dòng)指定Manual。適用于QA或開(kāi)發(fā)手動(dòng)點(diǎn)擊構(gòu)建時(shí)通過(guò)Jenkins參數(shù)選擇要執(zhí)行的模塊和測(cè)試類型這個(gè)作為兜底方案靈活度最高。為什么是四檔而不是更多我見(jiàn)過(guò)有人把測(cè)試策略細(xì)分成十幾檔結(jié)果維護(hù)成本太高最后大家都在手動(dòng)選參數(shù)。四檔覆蓋了日常開(kāi)發(fā)的主流程和特殊場(chǎng)景既保留自動(dòng)化判斷的空間又留有人工介入的口子屬于比較健康的復(fù)雜度。需要特別說(shuō)明的是檔位之間不是互斥關(guān)系。比如主分支的自動(dòng)構(gòu)建觸發(fā)了冒煙測(cè)試但同一分支上如果有手動(dòng)觸發(fā)的全量回歸參數(shù)策略計(jì)算會(huì)優(yōu)先采用手動(dòng)參數(shù)。這個(gè)優(yōu)先級(jí)邏輯在后面會(huì)具體講。2.2 四個(gè)核心參數(shù)怎么設(shè)計(jì)策略路由的本質(zhì)是參數(shù)驅(qū)動(dòng)。我在Jenkinsfile頂部定義了四個(gè)核心參數(shù)貫穿整條Pipeline參數(shù)名類型默認(rèn)值用途RUN_MODE選擇框AUTO自動(dòng)策略 / 手動(dòng)指定策略TEST_LEVEL選擇框SMOKE測(cè)試檔位SMOKE / MODULE / FULLMODULE_LIST字符串空當(dāng)檔位為MODULE時(shí)指定要測(cè)試的模塊列表逗號(hào)分隔IS_NIGHTLY布爾值false是否為定時(shí)觸發(fā)的夜間全量回歸在Jenkins Pipeline里parameters塊配置好這些參數(shù)后無(wú)論手動(dòng)構(gòu)建還是API觸發(fā)都可以覆蓋。這里的經(jīng)驗(yàn)點(diǎn)是參數(shù)要夠用但不要泛濫。早期我加了TEST_LEVEL之外還加過(guò)SKIP_UNIT、SKIP_API、RETRY_COUNT等等結(jié)果開(kāi)發(fā)同事根本不知道參數(shù)怎么選反而更依賴手動(dòng)觸發(fā)默認(rèn)行為。后來(lái)收斂成這四個(gè)參數(shù)每個(gè)參數(shù)都有明確的使用場(chǎng)景上手成本就低很多了。其中MODULE_LIST可以說(shuō)是最關(guān)鍵的一個(gè)參數(shù)。因?yàn)槟K名需要和代碼目錄、測(cè)試目錄的命名強(qiáng)一致我設(shè)計(jì)了一個(gè)約定后端服務(wù)模塊的命名統(tǒng)一使用service-xxx測(cè)試工程的目錄也按service-xxx組織。這個(gè)約定讓策略計(jì)算可以直接通過(guò)路徑匹配來(lái)反推模塊列表省掉了一張維護(hù)成本很高的映射表。2.3 策略路由的數(shù)據(jù)流理解了參數(shù)之后再看數(shù)據(jù)流就清楚了。整條Pipeline的策略路由分為三個(gè)階段第一階段是“計(jì)算策略”。Pipeline啟動(dòng)后首先進(jìn)入Init階段讀取觸發(fā)方式webhook、定時(shí)還是手動(dòng)、讀取GIT_*環(huán)境變量、讀取用戶填寫(xiě)的參數(shù)然后調(diào)用resolveTestStrategy()方法得到策略結(jié)果。第二階段是“分發(fā)執(zhí)行”。計(jì)算出來(lái)的策略結(jié)果寫(xiě)入一個(gè)Map變量例如[level: MODULE, modules: [service-a, service-b], needFull: false]。后續(xù)的Test階段通過(guò)讀取這個(gè)Map來(lái)決定執(zhí)行哪些測(cè)試任務(wù)而不是在測(cè)試任務(wù)里再重新做一次判斷。第三階段是“匯總反饋”。所有測(cè)試任務(wù)執(zhí)行完后統(tǒng)一收集JUnit報(bào)告計(jì)算通過(guò)率和耗時(shí)再根據(jù)策略信息生成向企業(yè)微信通知推送的內(nèi)容。這里有一個(gè)設(shè)計(jì)要點(diǎn)是策略計(jì)算和策略執(zhí)行必須解耦。我見(jiàn)過(guò)有的Pipeline把判斷邏輯塞進(jìn)每個(gè)stage的when條件里比如when { expression { return params.TEST_LEVEL FULL } }表面看沒(méi)問(wèn)題但一旦判斷條件復(fù)雜了多條件組合會(huì)讓when塊變得非?；逎?。我的做法是先算出一個(gè)“策略對(duì)象”后續(xù)所有節(jié)點(diǎn)都只消費(fèi)這個(gè)對(duì)象邏輯清晰且便于打日志調(diào)試。3. 實(shí)操過(guò)程與關(guān)鍵實(shí)現(xiàn)3.1 Jenkinsfile整體骨架直接看代碼。以下是簡(jiǎn)化后的Jenkinsfile骨架包含了參數(shù)定義、策略計(jì)算和執(zhí)行分發(fā)pipeline { agent { label linux-test } options { timestamps() timeout(time: 2, unit: HOURS) buildDiscarder(logRotator(numToKeepStr: 30)) disableConcurrentBuilds() } parameters { choice(name: RUN_MODE, choices: [AUTO, MANUAL], description: 自動(dòng)策略或手動(dòng)策略) choice(name: TEST_LEVEL, choices: [SMOKE, MODULE, FULL], description: 手動(dòng)指定測(cè)試檔位) string(name: MODULE_LIST, defaultValue: , description: 測(cè)試模塊列表逗號(hào)分隔) booleanParam(name: IS_NIGHTLY, defaultValue: false, description: 是否夜間定時(shí)構(gòu)建) } environment { PROJECT_NAME mall-platform BASE_REF develop TEST_RESULT_DIR ${WORKSPACE}/build/reports } stages { stage(初始化) { steps { script { STRATEGY resolveTestStrategy() echo 當(dāng)前測(cè)試策略: ${STRATEGY} } } } stage(構(gòu)建) { steps { echo 開(kāi)始構(gòu)建服務(wù)... // 實(shí)際構(gòu)建過(guò)程例如 mvn clean package -DskipTests } } stage(測(cè)試) { parallel { stage(單元測(cè)試) { when { expression { return shouldRunUnitTest(STRATEGY) } } steps { script { // 執(zhí)行選中模塊的單測(cè) } } post { always { junit testResults: **/target/surefire-reports/*.xml, allowEmptyResults: true } } } stage(接口測(cè)試) { when { expression { return shouldRunApiTest(STRATEGY) } } steps { script { // 執(zhí)行選中模塊的接口測(cè)試 } } post { always { junit testResults: **/target/failsafe-reports/*.xml, allowEmptyResults: true } } } stage(端到端測(cè)試) { when { expression { return STRATEGY.level FULL } } steps { script { // 執(zhí)行E2E測(cè)試 } } post { always { junit testResults: **/build/reports/e2e/*.xml, allowEmptyResults: true } } } } } stage(通知) { steps { script { notifyWechat(STRATEGY) } } } } }骨架里的STRATEGY變量是全局的在頂層通過(guò)def STRATEGY null聲明然后在初始化階段用script塊賦值。這利用了Groovy腳本在Jenkins Pipeline中的全局變量傳遞機(jī)制。3.2 策略計(jì)算邏輯怎么寫(xiě)策略計(jì)算的核心方法是resolveTestStrategy()。它的輸入是參數(shù)、分支名、變更文件列表輸出是一個(gè)Map。def resolveTestStrategy() { def branch env.GIT_BRANCH ?: env.BRANCH_NAME def level SMOKE def modules [] def needFull false // 手動(dòng)策略優(yōu)先 if (params.RUN_MODE MANUAL params.TEST_LEVEL ! SMOKE) { level params.TEST_LEVEL if (params.MODULE_LIST?.trim()) { modules params.MODULE_LIST.split(,).collect { it.trim() } } if (level FULL) { needFull true } return [level: level, modules: modules, needFull: needFull] } // 夜間定時(shí)構(gòu)建直接全量 if (params.IS_NIGHTLY) { return [level: FULL, modules: [], needFull: true] } // 主干分支策略master 和 release 分支合并前全量 if (branch master || branch release) { return [level: FULL, modules: [], needFull: true] } // 非主干分支先看變更文件列表再?zèng)Q定是冒煙還是模塊測(cè)試 def changeFiles getChangedFiles() if (changeFiles.isEmpty()) { return [level: SMOKE, modules: [], needFull: false] } def affectedModules parseModulesFromChangeFiles(changeFiles) if (affectedModules.size() 4) { // 改動(dòng)的模塊太多說(shuō)明是大范圍變更退回全量更安全 return [level: FULL, modules: [], needFull: true] } if (affectedModules.size() 0) { return [level: MODULE, modules: affectedModules, needFull: false] } return [level: SMOKE, modules: [], needFull: false] }這里面有兩個(gè)輔助方法值得單獨(dú)說(shuō)。getChangedFiles()的實(shí)現(xiàn)依賴Jenkins的changeSets。在多分支Pipeline里可以在script塊中直接讀取當(dāng)前構(gòu)建的變更集例如def getChangedFiles() { def files [] if (currentBuild.changeSets) { currentBuild.changeSets.each { changeSet - changeSet.items.each { item - item.affectedFiles.each { file - files.add(file.path) } } } } return files }這里有個(gè)坑currentBuild.changeSets只有在“分支被重新掃描后觸發(fā)構(gòu)建”的場(chǎng)景下才有值比如MR事件觸發(fā)的構(gòu)建。如果是定時(shí)構(gòu)建的第一次執(zhí)行變更集為空所以策略會(huì)回退到冒煙測(cè)試。這其實(shí)符合預(yù)期——定時(shí)構(gòu)建我本來(lái)就設(shè)置了IS_NIGHTLY參數(shù)來(lái)指定全量。parseModulesFromChangeFiles()的思路就是根據(jù)目錄前綴匹配模塊名。例如變更文件是service-order/src/main/java/...那么模塊名就是service-order。如果變更文件是common-utils/src/main/java/...那么模塊名歸入common-utils但這屬于公共模塊我會(huì)在匹配時(shí)把它忽略因?yàn)楣材K變更需要走全量。這個(gè)邏輯看似簡(jiǎn)單但有一點(diǎn)特別重要當(dāng)公共模塊被大量改動(dòng)時(shí)只跑關(guān)聯(lián)模塊是不夠的。所以我在策略里加了個(gè)閾值規(guī)則——當(dāng)受影響模塊數(shù)大于等于4個(gè)時(shí)升級(jí)為FULL策略。這個(gè)閾值是從兩次線上事故中總結(jié)出來(lái)的第一次公共模塊改動(dòng)只跑了兩個(gè)服務(wù)的接口測(cè)試結(jié)果牽連到第三個(gè)服務(wù)第二次是前端依賴升級(jí)后端模塊列表解析出來(lái)只有3個(gè)但數(shù)據(jù)庫(kù)連接池的公共配置被改了直接回歸暴露了配置錯(cuò)誤。定成4是折中的結(jié)果你們可以根據(jù)自己服務(wù)數(shù)量的三分之一量級(jí)來(lái)調(diào)整。3.3 各stage怎么消費(fèi)策略策略計(jì)算完了后面每個(gè)stage都需要消費(fèi)策略結(jié)果。消費(fèi)方式有兩種我在項(xiàng)目里都用到了。第一種是when條件判斷。比如端到端測(cè)試只有在STRATEGY.level FULL時(shí)才執(zhí)行單元測(cè)試和接口測(cè)試在策略為SMOKE或MODULE時(shí)也可能會(huì)執(zhí)行。具體判斷邏輯我封裝成了shouldRunUnitTest()這樣的方法def shouldRunUnitTest(Map strategy) { if (strategy.level FULL || strategy.level MODULE) { return true } if (params.RUN_MODE MANUAL params.TEST_LEVEL SMOKE) { return true } return false }第二種是動(dòng)態(tài)拼接測(cè)試命令。在接口測(cè)試stage里策略計(jì)算出的modules列表要轉(zhuǎn)成Maven或Gradle的命令行參數(shù)if [ ${STRATEGY.modules.size()} -gt 0 ]; then MODULES_PARAM$(echo ${STRATEGY.modules.join(,)} | tr , ) echo 本次接口測(cè)試模塊: ${MODULES_PARAM} # 實(shí)際執(zhí)行例如 # mvn test -pl $MODULES_PARAM -DtestApiTestSuite else echo 策略未指定模塊跳過(guò)接口測(cè)試 exit 0 fi這段邏輯放在script { sh ... }里通過(guò)Groovy的字符串拼接把策略信息傳給shell腳本。有一個(gè)細(xì)節(jié)Groovy里的List變量在傳給sh時(shí)不能直接當(dāng)作shell數(shù)組使用必須先在Groovy里拼成字符串再接進(jìn)shell腳本否則容易出現(xiàn)org.jenkinsci.plugins.scriptsecurity.sandbox相關(guān)的序列化異常。3.4 測(cè)試結(jié)果匯總與通知測(cè)試跑完結(jié)果不能白跑。我每次構(gòu)建結(jié)束都會(huì)做三件事收集JUnit報(bào)告、提取測(cè)試摘要、推送企業(yè)微信通知。JUnit報(bào)告收集在Jenkins Pipeline里就是junit方法注意要設(shè)置allowEmptyResults: true。如果不設(shè)置某個(gè)stage因?yàn)椴呗蕴^(guò)了導(dǎo)致沒(méi)有生成XML報(bào)告Pipeline會(huì)直接報(bào)錯(cuò)No test reports found。這個(gè)參數(shù)很多剛用Pipeline的人容易漏我剛開(kāi)始也在這上面卡了兩次。測(cè)試摘要可以通過(guò)currentBuild.testSummary這類插件提供的能力來(lái)獲取。比如在always塊里把測(cè)試總數(shù)、失敗數(shù)、跳過(guò)數(shù)寫(xiě)進(jìn)環(huán)境變量然后傳給通知腳本post { always { script { def summary currentBuild.testSummary ?: 無(wú)測(cè)試摘要 env.TEST_SUMMARY summary } } }企業(yè)微信通知我用的是httpRequest插件調(diào)用Webhook機(jī)器人接口。通知內(nèi)容里我會(huì)特意帶上策略信息和主要模塊列表【CI通知】mall-platform #123 構(gòu)建成功 分支feature/order-v2 測(cè)試策略MODULE (service-order, service-payment) 測(cè)試結(jié)果通過(guò) 128失敗 2已關(guān)聯(lián)到缺陷單 耗時(shí)12分30秒 構(gòu)建地址${BUILD_URL}為什么強(qiáng)制帶策略信息因?yàn)閳F(tuán)隊(duì)里其他人看到通知時(shí)需要知道“這次為什么只跑了這幾個(gè)模塊”。如果你不帶模塊信息后面出了問(wèn)題開(kāi)發(fā)會(huì)直接來(lái)質(zhì)問(wèn)你為什么漏測(cè)。帶著策略和模塊列表整個(gè)CI過(guò)程就變得可審計(jì)、可追溯了。4. 踩坑記錄與排查技巧4.1 常見(jiàn)問(wèn)題速查表動(dòng)態(tài)切換策略這套方案我前后迭代了四五個(gè)版本踩過(guò)的坑不算少。整理幾個(gè)最典型的供你排查時(shí)參考問(wèn)題現(xiàn)象根本原因解決辦法策略一直是SMOKE模塊測(cè)試從不觸發(fā)currentBuild.changeSets為空獲取變更文件失敗檢查webhook觸發(fā)類型MR事件必須由push事件攜帶變更列表觸發(fā)而不是依賴repository_dispatchJasonfile里執(zhí)行sh mvn test但找不到模塊工作目錄不是倉(cāng)庫(kù)根目錄或Agent上WORKSPACE路徑包含空格統(tǒng)一指定dir(${WORKSPACE}/backend)包裹執(zhí)行并在agent上檢查路徑并發(fā)構(gòu)建相互搶測(cè)試資源多個(gè)feature分支同時(shí)觸發(fā)接口測(cè)試共用同一批服務(wù)端口對(duì)共享測(cè)試環(huán)境加disableConcurrentBuilds()同時(shí)區(qū)分獨(dú)立環(huán)境的Agent標(biāo)簽手動(dòng)參數(shù)不生效系統(tǒng)總是自動(dòng)計(jì)算策略when條件的優(yōu)先級(jí)高于手動(dòng)參數(shù)邏輯參數(shù)還沒(méi)賦值就被過(guò)濾在resolveTestStrategy()里優(yōu)先判斷params.RUN_MODE MANUAL并確保parameters塊在agent之前定義JUnit報(bào)告統(tǒng)計(jì)不準(zhǔn)失敗用例不顯示測(cè)試報(bào)告生成路徑被多級(jí)目錄嵌套junit匹配規(guī)則太寬精確到具體目錄backend/**/target/surefire-reports/*.xml并檢查是否是用了allowEmptyResults掩蓋了路徑錯(cuò)誤定時(shí)構(gòu)建走了FULL策略但郵件通知里沒(méi)有策略信息env.TEST_SUMMARY在sh腳本里被覆蓋Groovy變量作用域沖突使用全局變量STRATEGY作為唯一數(shù)據(jù)源不重復(fù)賦值給環(huán)境變量構(gòu)建卡在策略計(jì)算階段getChangedFiles()在掃描大量文件時(shí)性能很差或Pipeline并發(fā)掃描導(dǎo)致死鎖限制變更文件數(shù)量超過(guò)一定量級(jí)直接返回全量策略4.2 幾個(gè)容易被忽略的細(xì)節(jié)除了上面表格里的問(wèn)題還有幾個(gè)經(jīng)驗(yàn)值得展開(kāi)講。第一個(gè)是Agent標(biāo)簽管理。我的測(cè)試Agent分為兩類linux-build和linux-test。構(gòu)建和測(cè)試分開(kāi)跑避免Maven編譯進(jìn)程搶占測(cè)試進(jìn)程的資源。測(cè)試Agent用restartOrdinarily方式調(diào)度如果該Agent上的測(cè)試服務(wù)版本不對(duì)經(jīng)常出現(xiàn)端口沖突或者污染上一次的測(cè)試環(huán)境。后來(lái)我在構(gòu)建腳本里強(qiáng)行執(zhí)行mvn clean并在每次構(gòu)建前清空${WORKSPACE}/build目錄才把這個(gè)問(wèn)題壓下去。第二條是不要在每個(gè)stage里重復(fù)計(jì)算策略。因?yàn)槲矣龅竭^(guò)這種情況Pipeline前面的STRATEGY變量在stage里被誤改或者并行stage里去訪問(wèn)全局變量時(shí)Groovy沙箱的綁定不一致直接導(dǎo)致NullPointerException。后來(lái)我規(guī)定STRATEGY只能由初始化階段寫(xiě)入后續(xù)所有stage都只讀不允許更新。代碼審查時(shí)這也成了一條規(guī)定。第三條是超時(shí)和重試機(jī)制。測(cè)試任務(wù)掛起是最煩人的。我在options里加了全局timeout同時(shí)在接口測(cè)試stage上還單獨(dú)加了retry(count: 2)。你可能會(huì)問(wèn)全量回歸那么長(zhǎng)超時(shí)設(shè)兩小時(shí)夠不夠我的經(jīng)驗(yàn)是先設(shè)一個(gè)保守時(shí)間跑兩周觀察實(shí)際耗時(shí)再往下調(diào)整。盡量不要一開(kāi)始就設(shè)很緊的超時(shí)否則一個(gè)慢用例就會(huì)讓整個(gè)構(gòu)建莫名其妙失敗。第四條關(guān)于jenkins可用環(huán)境變量。Pipeline里的env有很多變量來(lái)自插件和構(gòu)建配置比如BRANCH_NAME、GIT_COMMIT、CHANGE_TITLE、CHANGE_ID。我一開(kāi)始用GIT_BRANCH判斷分支后來(lái)發(fā)現(xiàn)它和BRANCH_NAME的表現(xiàn)不一樣多分支Pipeline里應(yīng)該優(yōu)先用BRANCH_NAME。這個(gè)小坑不踩一次根本不知道Jenkins的參數(shù)命名這么有“歷史包袱”。5. 這套方案的邊界與后續(xù)擴(kuò)展測(cè)試策略動(dòng)態(tài)切換不是萬(wàn)能的。它的核心假設(shè)是“變更影響范圍可以預(yù)測(cè)”對(duì)于模塊邊界清晰的中型項(xiàng)目這個(gè)假設(shè)成立對(duì)于那種一次提交改動(dòng)幾十個(gè)文件、尤其是公共底層模塊頻繁改動(dòng)的大型單體策略計(jì)算容易失效反復(fù)觸發(fā)全量回歸后反而不如直接把全量跑拆成并行分片來(lái)得實(shí)惠。我目前已經(jīng)在嘗試的后續(xù)擴(kuò)展有兩個(gè)方向。一個(gè)是自動(dòng)失敗用例重跑。全量回歸中偶爾會(huì)有幾個(gè)用例因?yàn)榄h(huán)境抖動(dòng)失敗但并非真實(shí)缺陷。我在策略里新增了“失敗用例自動(dòng)重跑一次仍然失敗才標(biāo)記為真失敗”的邏輯這樣有效減少了人工確認(rèn)的工作量。另一個(gè)方向是結(jié)合AI分析測(cè)試影響。Jenkins已經(jīng)支持AI Agent插件通過(guò)分析代碼變更的調(diào)用鏈和測(cè)試用例之間的關(guān)聯(lián)關(guān)系自動(dòng)生成受影響模塊列表。現(xiàn)在我的parseModulesFromChangeFiles()還是基于目錄約定的靜態(tài)匹配未來(lái)如果能接入AI分析策略的準(zhǔn)確性和精細(xì)度還能再提升一個(gè)臺(tái)階。不過(guò)我要潑一盆冷水動(dòng)態(tài)切換策略這件事真正的難點(diǎn)不在于代碼怎么寫(xiě)而在于團(tuán)隊(duì)是否信任這套策略。要讓開(kāi)發(fā)放心測(cè)試結(jié)果和策略判斷必須透明可查要讓QA放心手動(dòng)指定策略必須始終兜底要讓團(tuán)隊(duì)放心降級(jí)規(guī)則例如公共模塊改動(dòng)量過(guò)大就直接全量必須清晰寫(xiě)在文檔里。CI的本質(zhì)是團(tuán)隊(duì)協(xié)作的潤(rùn)滑劑如果為了省時(shí)間而犧牲了信任那這個(gè)方案走不遠(yuǎn)。我做這套方案最深的感受是Jenkins Pipeline的強(qiáng)大之處從來(lái)不在于語(yǔ)法多花哨而在于它能讓你把“構(gòu)建流程”當(dāng)成一個(gè)真正的軟件工程來(lái)設(shè)計(jì)。參數(shù)、策略、測(cè)試、通知每一層都可以獨(dú)立演進(jìn)穩(wěn)定的底層支撐靈活的頂層。如果你也想在團(tuán)隊(duì)里做類似的事建議從一檔全量、一檔冒煙開(kāi)始跑通之后再加模塊級(jí)測(cè)試一步步把復(fù)雜度控制住。測(cè)試策略動(dòng)態(tài)切換說(shuō)到底不是技術(shù)問(wèn)題而是“如何讓CI更懂業(yè)務(wù)”的問(wèn)題。