可靠的服務需要可靠的發布流程。發布工程就是「把程式碼庫變成生產環境裡運行的東西」這整條路——它的核心信念是：每次發布都該是可重現、可自動化、可追溯的，而不是一片獨一無二的雪花。
🧠 Intuition
TIP
大多數線上事故是由 binary 或設定的推送觸發的。但這些變更（修 bug、補安全、上新功能）又是業務必需。解法不是拒絕變更，而是讓發布流程本身穩到「敢頻繁地小步發」。
- 自助服務（Self-Service）：發布工程提供工具與最佳實踐，讓產品團隊自己掌控發布節奏，只在出問題時才需專人介入——這是規模化的前提。
- 高速發布（High Velocity）：發得越勤，版本間差異越小、測試除錯越容易。有的團隊每小時 build、有的採 Push on Green（測試全綠自動推）。
- 封閉式 Build（Hermetic Build）：兩個人在不同機器、同一 revision 建構，必須得到相同結果——build 只依賴明確版本的編譯器與相依，不依賴機器上裝了什麼。
- 設定即程式碼：設定變更是不穩定的大來源；把設定存進程式碼倉庫、強制 code review，才管得住。
⚖️ Tradeoffs
主線開發 + 分支發布 + Cherry-pick — 讓每次發布內容明確
- 程式碼全進主線（mainline）；發布時從主線特定 revision 分支，從不合回主線。
- 修舊版 bug 用 cherry-pick：在原 revision 上重 build，只把特定後續變更挑進來——連 build 工具都與 revision 對齊，避免「今天的編譯器 build 上個月的碼」。
- 好處：每次發布確切含哪些變更都可查（自動產生變更報告），SRE 出狀況時能秒定位。
- 代價：cherry-pick 的內容可能在主線從未出現過，所以發布分支要重跑測試並留稽核軌跡。
設定管理的四種模型 — 沒有單一最佳解
- 直接用主線設定：改 head 設定檔、binary 不重 build。最簡單，但易發生「checked-in 版本 ≠ running 版本」。
- 設定與 binary 同包：部署只裝一個套件；但兩者綁死，適合設定少或每次都會動的專案。
- 設定獨立打包：發揮 hermetic 原則，可獨立 cherry-pick 設定（不必重 build binary），用版本 ID 重建某時間點的設定組合。
- 從外部儲存讀設定：需頻繁或運行中動態變動時，存外部設定服務。專案依需求自選，別追求單一銀彈。
🔑 Takeaways
- 發布工程的目標是讓發布可重現、可自動化、可追溯——「不該是雪花」；大多數事故來自推送，所以流程要穩到敢小步快發。
- 四支柱：自助服務、高速發布、封閉式 build、政策強制執行；主線開發 + 分支發布 + cherry-pick 讓每次發布內容明確可查。
- 設定是不穩定大源頭——一律進倉庫、強制 review；四種設定模型依需求選，沒有單一最佳解。
No notes yet — jot your takeaways or Q&A here.