🎯 什麼情境該想到我
分工：《DevOps 手冊》的部署相關實踐已經展開成型錄 → 版本控管一切、主幹開發、測試金字塔、自動化自助部署、保護部署管線、解耦部署與發布、藍綠部署、金絲雀發布、功能開關、黑啟動。這張補怎麼量交付能力（DORA）、管線階段的排序原則，以及 Go 專案的具體管線。
當「每次發布都是大工程/要熬夜/容易出錯」，你想讓上線變成頻繁、可靠、無聊的日常時。
⚙️ 怎麼用
- 版本控管一切：程式碼、設定、環境、基礎設施（IaC）都進 git。
- 持續整合（CI）：每次提交自動建置 + 跑自動化測試，保持主幹隨時可發布。
- 建部署管線：一條自動化流水線把「提交 → 測試 → 部署」串起來，一鍵（或自動）到各環境。
- 小批量、頻繁發布：批量越小，風險越小、出錯越好定位。
- 降低發布風險：藍綠部署、金絲雀、功能開關（feature flag）、可快速回滾。
★ 怎麼知道交付能力有沒有進步：DORA 指標
DORA 目前把軟體交付表現分成吞吐量和不穩定度兩組（依 dora.dev，2026-09-25 查證）：
| 組別 | 指標 | 定義 |
|---|---|---|
| 吞吐量 | 變更前置時間 | 一個變更從提交到版本控制到部署到正式環境的時間 |
| 部署頻率 | 一段時間內的部署次數，或兩次部署之間的間隔 | |
| 失敗部署的恢復時間 | 一次需要立即介入的失敗部署，要多久才恢復 | |
| 不穩定度 | 變更失敗率 | 部署後需要立即介入的比例 |
| 部署重工率 | 因為正式環境事故而進行的計畫外部署比例 |
- 「失敗部署的恢復時間」取代了早期的 MTTR——範圍縮小到因部署造成的失敗，而不是所有事故。
- 這兩組要一起看：只衝吞吐量而不穩定度上升，代表在把問題更快送上線；DORA 的研究結論是兩者可以同時變好，因為小批量的變更更快也更安全。
★ 管線階段的排序：便宜又快的在前面
每個階段都是一道篩子。越早失敗越便宜，所以把「跑得快、最常抓到問題」的階段放前面：
| 順序 | 階段 | 典型耗時 | 為什麼放這裡 |
|---|---|---|---|
| 1 | 格式、靜態檢查 | 秒 | 最便宜；錯了就不必浪費時間建置 |
| 2 | 單元測試 | 秒～分鐘 | 抓大部分邏輯錯誤 |
| 3 | 建置產物（二進位檔、容器映像） | 分鐘 | 只建置一次，之後每個環境都用同一個產物 |
| 4 | 整合測試、契約測試 | 分鐘 | 需要資料庫等外部資源 |
| 5 | 部署到預備環境 + 冒煙測試 | 分鐘 | 驗證「能部署、能啟動」 |
| 6 | 正式環境：金絲雀 → 全量 | 分鐘～小時 | 用真實流量驗證，出問題自動回滾 |
「只建置一次」是關鍵原則：如果每個環境各自重新建置，你在預備環境測過的東西，就不是正式環境上跑的東西。
★ Go 專案的管線（對應上表 1–3）
# 1. 靜態檢查
test -z "$(gofmt -l .)" # 有未格式化的檔案就失敗
go vet ./...
golangci-lint run --new-from-rev=origin/main # 只擋新增的問題（見「破窗」卡的棘輪）
# 2. 測試：競爭偵測 + 不使用快取
go test -race -count=1 ./...
# 3. 建置：可重現、帶版本資訊
CGO_ENABLED=0 go build -trimpath -o bin/app ./cmd/app-trimpath：從二進位檔移除本機路徑，讓不同機器建置出的結果一致。- Go 會自動把版本控制資訊寫進二進位檔：在 git 倉庫中建置後，用
go version -m bin/app可以看到vcs.revision（commit 雜湊）、vcs.time、vcs.modified（建置時工作區是否有未提交的修改）。本機以 Go 1.26.4 驗證過（2026-09-25）。程式內可用runtime/debug.ReadBuildInfo()讀取，放進/version端點——事故時第一個問題就是「現在線上跑的是哪個 commit」。 CGO_ENABLED=0產生靜態連結的二進位檔，可以放進極小的容器映像（scratch或 distroless）。
★ 回滾要比修復快
管線的最後一道防線是回滾。設計目標：
- 回滾是一個按鈕或一個指令，不需要重新建置（直接部署上一個已建置好的產物）。
- 資料庫遷移要向後相容（先加欄位、程式碼上線、再移除舊欄位——見 工具-小步重構的平行改動），否則程式碼可以回滾，資料庫回不去。
- 定期演練回滾。從沒用過的回滾程序，出事時很可能不能用。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
-
沒有可靠的自動化測試，CD 只是「更快地把 bug 送上線」；測試是前提。
-
管線太慢，大家就會繞過它：主幹上的管線超過 15–20 分鐘，工程師就會開始累積大批變更一起送，失去小批量的好處。要持續量測並縮短管線時間。
-
不穩定的測試會毀掉對管線的信任：見 工具-破窗理論與軟體熵——flaky test 要立刻隔離。
🔗 相關工具
- 工具-三步工作法 —— 上位框架，部署管線是第一步「流動」最具體的基礎建設
- 工具-遙測與監控 —— 必要配套，發布變頻繁之後，出事能否即時看見決定敢不敢繼續快
- 工具-降低在製品WIP —— 互為因果，管線順暢才可能小批量交付，WIP 也才降得下來