Aidan Wang

Engineering Manager · 寫複雜系統與技術領導

用一張圖加精簡的文字,把複雜的系統講清楚。

目前寫了 16 個系列、181 篇文章——從 SQL、DDIA、Kafka、Airflow、Kubernetes、SRE,到帶團隊的心得與實戰的電商系統設計。

從這裡開始 → 關於我

精選系列

Designing Data-Intensive Applications 讀書筆記

12 篇

逐章讀《DDIA》:資料模型、儲存引擎、複寫、分區、交易,一路到分散式系統的取捨。

Re:從零開始做直播代購電商平台

21 篇

戰爭故事:拿真實做過的直播代購電商平台重打一次——留言下單、庫存、金流物流;當年怎麼做、重來怎麼設計。

成為 Tech Leader 讀書筆記

8 篇

讀《成為 Tech Leader》——寫給正在或即將帶人的工程師的筆記與反思。

還有 Redis、Kafka、Spark、Airflow、K8s、SRE 等共 16 個系列 → 看全部

最新文章

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

Tools · Guides · RSS