CI 還不夠：它聚焦開發團隊，產出往往還要丟進冗長的手動測試與發布流程。部署管線把「從版本控制到使用者手中」這整條路自動化並模型化——每次 commit 啟動一個實例，隨著逐階段通過，信心增加、投入資源增加、環境越來越接近生產。
🧠 Intuition
TIP
四個核心階段：Commit（編譯 + 單元測試 + 程式碼分析）→ 自動驗收測試（滿足使用者需求與規格）→ 手動測試（探索性/可用性/UAT）→ 發布（交付到 staging/production）。目標是儘早淘汰不合格的候選版本，並把失敗根因最快回饋給團隊。
- 管線把交付變成pull system：測試團隊自助部署到測試環境、維運一鍵部到 staging/production、開發看到每個 build 過了哪些階段、管理者盯 cycle time 與吞吐。
- 快速回饋的關鍵是可見性：看得到哪個 check-in 過了哪一階段，問題就能立刻追溯到導致失敗的那次變更。
- Commit 階段要快：開發提交後理想 5 分鐘、最多 10 分鐘內出結果，否則工程師已切換上下文；超時就把測試拆成平行套件。
- 「pipeline」一詞借自處理器的指令管線化——樂觀地假設後續階段會過、在背景平行推進候選版本，猜錯就丟棄、沒有損失。
⚖️ Tradeoffs
每階段各自重編、各環境各自部署 — 引入差異的溫床
- 在 commit、acceptance、capacity 各階段反覆從原始碼編譯，編譯器/函式庫/設定的差異都可能改變行為。正解：只建置一次二進位檔，後續階段靠 hash 驗證重用同一份。
- 二進位檔不該是環境特定的——把「各環境相同的程式碼」與「各環境不同的設定」分離，否則建置系統會爆炸式複雜（作者見過要五人全職維護）。
- 每個環境用相同方式部署：production 部署頻率最低、風險最高，只有在其他環境部過數百次後，才能把部署腳本從錯誤來源清單中排除。
定時排程 vs 即時流動 — 回饋週期的差異
- 傳統「每小時 build、每晚跑驗收、週末跑容量」讓回饋拖到數天後才到。管線改為每次 check-in 觸發第一階段、每階段成功即觸發下一階段。
- 智慧排程：acceptance 還在跑時新 commit 不重複觸發，等跑完針對最新版本執行；此排程只適用全自動階段，手動測試環境按需觸發。
- 任一階段失敗就 stop the line：整個團隊擁有這個失敗、先修再說——不只 commit 階段，整條管線都適用。
🔑 Takeaways
- 部署管線把「版控 → 使用者」自動化為四階段（Commit → 自動驗收 → 手動測試 → 發布），逐階段增信心、儘早淘汰壞候選。
- 三大實踐：只建置一次二進位檔、每個環境同法部署、每次變更即時流過管線；commit 階段控在 5–10 分鐘。
- 最重要的全域指標是 cycle time（一行變更多久能可靠上線）；用約束理論找瓶頸、持續縮短回饋週期。
No notes yet — jot your takeaways or Q&A here.