Release Cadence、Hotfix 與六種反模式
一句話總結：Release 頻率沒有標準答案，看團隊成熟度。Hotfix 只給 P0 用。六種反模式讓你的 Release 從無聊變成噩夢。
結論先講：如果你的 Release 沒有固定節奏——想到就 Release、PM 催了就 Release——你的團隊會疲於奔命。不可預測的 Release 節奏是最大的反模式。
Release Cadence：多久 Release 一次？
| 策略 | 週期 | 適合誰 |
|---|---|---|
| Continuous | 每次 commit | SaaS、內部工具。需要超成熟的 CI/CD |
| Weekly | 每週固定日 | 中型 SaaS、快速迭代 |
| Bi-weekly | 與 Sprint 對齊 | Scrum 團隊。最常見的選擇 |
| Monthly | 每月一次 | Enterprise / B2B |
| Release Train | 固定時間、彈性 scope | 大型多團隊協作 |
怎麼選？
- < 5 人、產品初期：Weekly 或 Continuous
- 5-15 人、產品穩定：Bi-weekly（跟 Sprint 對齊）
- > 15 人、多團隊：Release Train
- Enterprise / B2B：Monthly
Continuous 聽起來很美好——每次 commit 都自動上線。但前提是你有非常成熟的自動化測試、Feature Flag、監控系統。大多數團隊沒有，所以不要硬上。
Hotfix：只給 P0 用的特急件
Hotfix 的定義必須非常嚴格。不是所有「很緊急」的問題都是 Hotfix。
| 算 Hotfix | 不算 Hotfix |
|---|---|
| 核心功能完全中斷 | 非核心功能的 Bug |
| 資料遺失風險 | UI 顯示問題 |
| 安全漏洞正在被利用 | 效能輕微退化 |
| 法規合規問題 | 「很重要但不緊急」的 Bug |
如果問題可以等到下次 Regular Release 修復，那它不是 Hotfix。
Hotfix 是 Regular Release 的壓縮版，省略部分步驟但保留核心品質關卡：
| 階段 | Regular Release | Hotfix |
|---|---|---|
| Planning | 完整規劃 | 問題即 scope |
| Development | 按 Sprint | 立即修復（< 數小時） |
| Code Freeze | 1-5 天 | 略 |
| QA | 完整測試 | 修復功能 + 相關回歸 |
| Staging | UAT + 效能 | 快速功能驗證 |
| Go/No-Go | 正式會議 | Tech Lead 口頭確認 |
| Deploy | 計畫時間 | 盡快 |
| Post-Release | 72h 監控 + 覆盤 | 24h 監控 + 簡短覆盤 |
Hotfix 也要走流程，但是精簡版。 即使時間緊迫，Code Review 不能跳、Staging 驗證不能跳、Smoke Test 不能跳。「緊急修復造成的二次事故」比原始問題更嚴重的案例多到數不清。
六種 Release 反模式
1. 「Release 就是 Deploy」
所有討論都圍繞 CI/CD pipeline 配置，沒人管「什麼功能應該上」、「利害關係人同意嗎」。結果：PM 說「這不是我要的」、客服不知道有新功能。
解法： 明確區分 Deployment（技術團隊）和 Release（產品決策）。
2. Feature Freeze 形同虛設
Freeze 後 PM 不斷加功能——「就這一個，很快就好」。工程師默許，因為拒絕很尷尬。結果：Freeze 後的變更沒充分測試，成了 Bug 溫床。
解法： Freeze 規則要有管理層背書。有正式 Exception Process。追蹤 Exception 數量——太多代表規劃有問題。
3. QA 瓶頸
所有 Feature 最後一天才丟給 QA。QA 時間被壓縮，只能表面測試。
解法： QA 從開發階段就介入（Shift Left）。完成一個功能就測一個。增加自動化測試減少手動回歸負擔。
4. 沒有 Rollback Plan
Release 計畫裡沒有 Rollback Plan，或有但從沒演練過。出問題才發現 rollback script 跑不動、migration 回不去。
解法： 沒有 Rollback Plan = 不准上線。每次 Release 前在 Staging 演練。Migration 必須附 rollback script。
5. 半夜 Release
理由是「流量低、影響小」。實際結果：工程師疲勞操作犯錯、判斷力下降、出問題要叫醒更多人。
解法： 用 Blue-Green 或 Canary 實現零停機部署，不要靠半夜低流量規避風險。正常情況選工作日上午。
6. 覆盤虛應故事
每次都說要覆盤，但不是沒開會、就是開了會沒行動項目、有行動項目沒人跟進。同樣的問題每次重複出現。
解法： 行動項目進 Jira。有負責人、有到期日。下次覆盤第一項議程：上次的項目做了嗎？
系列總結
Release 方法論的核心是：在正確的時間點做正確的檢查，確保每一次 Release 都是有意識的產品決策，而非碰運氣的技術動作。
| 階段 | 一句話 |
|---|---|
| Planning | 定義範圍，Time-boxed |
| Development | 持續整合，開發者自測 |
| Code Freeze | 穩定化，不加功能 |
| QA | 品質簽核，Bug 分級 |
| Staging | Production-like 驗收 |
| Go/No-Go | 多方決策，Rollback Plan 必備 |
| Production | Smoke Test，Feature Flag 逐步啟用 |
| Post-Release | 監控 72h，覆盤有追蹤 |
好的 Release 應該是無聊的。如果你的團隊能按照 checklist 平靜地完成 Release、從容地看監控、然後收工下班——這才是 Release 方法論成功的標誌。
系列文章：
- Release 方法論（一）：Release vs Deploy
- Release 方法論（二）：Code Freeze 與 QA 驗證
- No-Go
- Release 方法論（四）：Production Release 與 Post-Release
- 你在這裡 → Release 方法論（五）：Release Cadence、Hotfix 與反模式
延伸閱讀：
「Release 頻率就像吃飯——太少會餓死（功能堆積），太多會撐死（流程跑不完）。找到你的節奏最重要。」