Release 方法論（一）：Release 不等於 Deploy——從規劃開始的紀律

cover

Release 不等於 Deploy——從規劃開始的紀律

一句話總結：Deploy 是把程式碼搬到伺服器，Release 是決定什麼功能在什麼時間對什麼用戶可見。兩者不是同一件事。

結論先講：好的 Release 應該是無聊的。如果每次 Release 都像打仗一樣刺激，你的流程有問題。Release 的品質在規劃階段就決定了一半——範圍失控的 Release，後面流程再嚴謹也救不回來。

每一個資深工程師都有至少一個「Friday deploy 恐怖故事」。週五下午五點，有人說「這個小改動很簡單，deploy 一下就好」，結果週五晚上到週日都在救火。

問題出在哪？很多團隊把 Release 和 Deployment 當成同一件事。

Deployment 是技術動作——把程式碼從 A 搬到 B。CI/CD pipeline 的工作，工程師的日常操作。Release 是產品決策——決定什麼功能在什麼時間對什麼用戶可見。涉及產品策略、市場時機、風險評估。

一個成熟的團隊可以每天 deploy 數十次，但每兩週才 release 一次。Deploy 是把彈藥送上前線，Release 是決定什麼時候開火。

Feature Flag 正是實現「deploy 與 release 解耦」的關鍵——程式碼已經部署在 Production，但功能對用戶不可見，直到你決定打開開關。

聽起來很熟悉？這些都是 Release 方法論要解決的問題：可預測性、品質保障、風險控制、責任歸屬、持續改善。

完整的 Release 流程有八個階段，每個階段都是下一個的前提：

#	階段	核心問題	關鍵交付物
1	Feature Planning	這次 Release 什麼？	Release Scope 文件
2	Development	如何有紀律地開發？	自測完成的 Feature Branch
3	Code Freeze	什麼時候停止加功能？	穩定的 Release Branch
4	QA 驗證	品質達標嗎？	QA Sign-off Report
5	Staging 驗收	Production-like 環境正常嗎？	Staging 簽核
6	Go/No-Go	準備好上線了嗎？	決策記錄
7	Production Release	如何安全部署？	Smoke Test 通過
8	Post-Release	上線後穩定嗎？	覆盤記錄

Release 的範圍必須在一開始就定義清楚。用 MoSCoW 分級：

時間固定還是範圍固定？ 建議用 Time-boxed 模式。到日期就發車，沒趕上的等下一班。「所有功能做完才 Release」的模式，常常導致 Release 永遠在延期。

Feature Flag 在這個階段就該規劃——哪些功能用 Flag 控制？啟用順序是什麼？記得，Feature Flag 在功能穩定後要清理，不然程式碼裡會累積一堆過期的 Flag。

開發階段的紀律直接決定了後續的順暢度。

持續整合 > Big-bang Merge。 Feature Branch 不超過 3-5 天。如果功能太大，拆成可獨立合併的小單元。每日 merge main 到 feature branch，保持同步。CI Pipeline 是門禁——lint、test、build 沒過不能合併。

Big-bang Merge 是什麼？就是所有 Feature Branch 在 Release 前才一次合併。這幾乎必然導致大量衝突。我見過團隊花整整兩天在解衝突，然後趕在 deadline 前 Release 一堆沒有經過充分測試的程式碼。

Developer Self-testing： 在提 MR 之前，開發者自己先過一遍：Happy Path 測過嗎？Edge Case 驗過嗎？錯誤處理路徑確認過嗎？有寫測試嗎？Migration 能 rollback 嗎？新環境變數有文件化嗎？

這不是 QA 的前哨站嗎？沒錯，就是。QA 不該是第一道品質關卡，開發者自己才是。

Release 不等於 Deployment——前者是產品決策，後者是技術動作。Release 有八個階段，從規劃到上線後監控形成閉環。Feature Planning 用 MoSCoW 分級定義範圍，搭配 Time-boxed 模式。開發階段要持續整合、開發者自測。

下一篇看 Code Freeze 和 QA 驗證。

系列文章：