#ci-cd

checkout sh 'build' sh 'test' deploy 每個步驟之間,把「執行到哪 + 變數裡有什麼」整包寫到磁碟 ⚡ controller 在這裡重啟 重啟後:從最後一次存檔的狀態接著跑,不用從頭來過 為了能隨時存檔,Jenkins 把你的 Groovy 轉成「可以一步步暫停」的形式(CPS) 而能存檔的前提是:所有還活著的變數,都必須可以序列化 NotSerializableException、@NonCPS、某些寫法行為詭異——全部源自這一句話

Jenkinsfile 不是 Groovy:CPS、序列化與沙箱

· tech · 約 6 分鐘 · 📚 Jenkins 學習筆記 #9

這個系列到目前為止給過三次同一個建議:Jenkinsfile 只做編排,邏輯放到 shell 腳本或 src/ 的 class 裡。 但我給的理由一直都很軟——好讀(半夜看它的人不一定會 Groovy…

#jenkins#ci-cd#groovy

payment-api(repo) main feature/refund feature/webhook PR #12 PR #15 webhook掃描 Multibranch有 Jenkinsfile 的就自動長一個 job job: main跑 main 的 Jenkinsfile job: feature/refund跑「它自己那版」 job: feature/webhook跑「它自己那版」 job: PR-12合併前先驗 job: PR-15合併前先驗 每個分支跑「它自己那一版」Jenkinsfile,不是共用一份 所以改 pipeline 的 PR,是用改過之後的版本跑的——建置流程的變更,合併前就被驗過了 分支刪掉,對應的 job 也要跟著消失(孤兒 job 清理策略)——否則就是下一批要清的堆積

Multibranch 與 PR 觸發:讓每個分支都有自己的 pipeline

· tech · 約 11 分鐘 · 📚 Jenkins 學習筆記 #8

前面七篇談的都是「一條 pipeline」。但真實的 repo 從來不只有一條路:main 上有人在合、三個 feature branch 在跑、還有兩個 PR 等著 review。 這篇處理的就是這…

#jenkins#ci-cd#branching

✗ 十份複製貼上的 Jenkinsfile 專案 A · 200 行修過安全性設定 專案 B · 205 行沒跟上那個修補 專案 C · 180 行兩年前複製的版本 專案 D · 240 行有人改過,原因失傳 專案 E · 200 行複製自 C(所以也舊) 沒有人知道哪一份才是對的 一個修補要改十次,而且一定會漏掉兩個 「最佳實務」只存在於最早那份,之後只有漂移 ✓ 收斂成一份,各自釘版本 A · 15 行@1.4.0 B · 15 行@1.4.0 C · 18 行@1.5.0 D · 22 行@1.4.0 E · 15 行@1.5.0 pipeline-lib一份 · 有版本 一次修補,全體受惠 但同一件事的反面是:一改,可能全炸 所以要釘版本——升不升、什麼時候升,由專案自己決定 收斂解決的是「漂移」,版本解決的是「連坐」 只做前者不做後者,你會把十個獨立的小問題,換成一個全公司同時發作的大問題

Shared Library:把十份幾乎一樣的 Jenkinsfile,變成公司資產

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #7

第 2 篇的結論是:把 pipeline 寫成程式碼、放進 repo。這件事在一個專案上是純粹的勝利,但當公司有十個、三十個專案之後,會長出一個新問題——十份幾乎一樣、但又不完全一樣的 Jenkins…

#jenkins#ci-cd#pipeline

✗ 一把萬能鑰匙,放 Global prod-deploy-keyGlobal · 永久有效 · 全權限 前端 build 後端 build 工具 job 外部 PR build 能讓任何一個 build 跑起來的人 = 拿到了 Production 的鑰匙 ✓ 按 folder 切 + 短期票 folder: web只有 npm registry token folder: api只有內部 maven 憑證 folder: deployprod 憑證只在這裡 · 只能部署,不能刪叢集每次 build 現發,build 結束就失效 PR build 在 web / api folder 底下 它根本看不到 deploy folder 的憑證 看憑證只問三題:能做什麼 · 活多久 · 誰拿得到 三題都答得出來,才輪得到討論「有沒有加密」——那從來不是重點

憑證管理:機密怎麼進 pipeline,又不會漏出去

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #6

第 2 篇的結論是:pipeline 要寫成程式碼、進 git、讓每個人都能 review。這是整個系列的立場,但它有一個必須同時付的代價——這條路上的每一行,所有能讀這個 repo 的人都看得到。 …

#jenkins#ci-cd#security

序列:一個接一個 Unit 4m Integration 6m 1m Image 3m 14m 010 分 平行:同時開跑 Unit 4m Integration 6m ← 最慢的那條 1m Image 3m 6m —— 總時間 = 最慢的那一條 所以再加平行不會更快,要動的是那條 6 分鐘的 平行的代價:每條各佔一個 executor 格子 · 同機互搶 CPU 與硬碟 · 日誌交錯變難讀 格子不夠時,「平行」會退化成「排隊」——只是排在 Jenkins 內部,你在 UI 上看不出來

進階 pipeline:平行、條件、失敗處理與那個很貴的人工關卡

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #5

前面四篇處理的是「在哪跑」與「東西放哪」。這一篇回到 Jenkinsfile 本身:同樣一條會動的 pipeline,怎麼讓它跑得快、失敗得清楚、而且不會在半夜卡住一台機器。 這批東西的共同點是:它們…

#jenkins#ci-cd#pipeline

① build #41 跑完target/ · node_modules/build 時產生的 config.yml.gradle / .m2 快取全部留在 workspace 裡 ② build #42 開始checkout 更新 git 追蹤的檔案沒被追蹤的殘骸 → 原封不動(它不是 clean,只是 update) ③ build #42 綠燈 ✓但測試讀到的是 #41 產生的那份 config.yml換一台乾淨機器 → 爆 同一個 workspace 目錄,被 #41、#42、#43… 重複使用——它是一個沒人在管的共用狀態 檢驗問題:同一個 commit,在一個全新的環境跑,還會過嗎? 答不出來,你的綠燈就是靠殘留撐著——而殘留遲早會被清掉、或換一台 agent 就消失 這也是「在我機器上明明可以」的反面:在 CI 上明明可以

Workspace 與 Artifact:build 出來的東西去哪了

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #4

上一篇解決了「在哪台機器上跑」。這一篇往下挖一層:跑起來之後,檔案到底放在哪、留多久、誰看得到。 這聽起來很枝微末節,但它其實是整個系列主軸裡「可重現」最常破功的地方——而且破得很安靜:你的 CI 一…

#jenkins#ci-cd#build

① 觸發webhook / PR ② 佇列等一個空格子 ③ 依 label 媒合Jenkinsfile 說:linux && docker agent-alabel: linux docker3 個 executor,還剩 1 格 → 派這台 agent-blabel: linux全空,但沒有 docker → 輪不到它 agent-maclabel: mac簽 iOS 用的,別的工作不派來 排隊等的是 executor 格子,不是機器 一台 agent 有幾個 executor,就能同時跑幾個 build——格子開太多,大家一起搶 CPU 與硬碟 而 label 不符的 agent,就算整台閒著也不會被派工:你的 build 在等的往往不是「機器」,是「對的機器」

Controller 與 Agent:工作到底在哪台機器上跑

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #3

上一篇那份 Jenkinsfile 裡有一行 sh './scripts/ci-build.sh'。它到底在哪台機器上執行? 這個問題聽起來很基本,但它決定了三件事:你的 build 要等多久、失敗時…

#jenkins#ci-cd#infrastructure

設定住在 Jenkins UI 上 v1 · 1月 v2 · 3月 v3 · 8月 job 設定(config.xml)只有「現在」這一份 checkout v1 想重 build 一次 配到的是 8 月的設定,不是 1 月的 那顆產物,再也組不回來 設定住在 repo 裡 v1 · 1月 v2 · 3月 v3 · 8月 Jenkinsfile Jenkinsfile Jenkinsfile 每個 commit 自己帶著當時的建置方式 checkout v1 想重 build 一次 拿到的就是 1 月那份 Jenkinsfile 程式碼與建置方式永遠同版本 「這版是怎麼 build 出來的?」——只有右邊答得出來 同一個 commit、同一次 review、同一次 revert:可審查買一送二,順便買到可重現與可回滾

第一個 Jenkinsfile:pipeline as code 為什麼贏過 UI 點按鈕

· tech · 約 7 分鐘 · 📚 Jenkins 學習筆記 #2

上一篇最後那份 Jenkinsfile 只有二十行,語法簡單到不需要解釋。但我還是要為它寫一整篇——因為這二十行真正的價值不在語法,而在它躺在哪裡。 同一個 build,你可以在 Jenkins 的 …

#jenkins#ci-cd#pipeline

同一條路,三個名字——差別只在自動化走到哪裡 ① 提交程式碼push / open PR ② 建置 + 測試自動、每次都跑 ③ 打包產物一顆可部署的東西 ④ 測試環境驗收隨時可上線的狀態 ⑤ 上 Production誰按下這一步? CI(持續整合) 合回主幹 + 每次都自動驗證 Continuous Delivery(持續交付) 隨時可上線,但人按 Continuous Deployment(持續部署)——過關就自動上,沒有那顆按鈕 兩個 CD 的差別不是技術,是你敢不敢把那顆按鈕拿掉 敢不敢,取決於前面幾關擋得住多少——這也是為什麼品質關卡與回滾是後面幾篇的重點

Jenkins 是什麼:CI 不是「有跑測試」,是「頻繁合回主幹」

· tech · 約 13 分鐘 · 📚 Jenkins 學習筆記 #1

大部分人第一次碰 Jenkins,情境都差不多:公司有一台跑很久的 Jenkins,你要在上面「加一個 job」。點進去、複製隔壁專案的設定、改幾個欄位、按存檔——會動了,收工。這樣用了兩年,你會很熟…

#jenkins#ci-cd#concept