[methodology] 產品 Release 方法論

產品 Release 方法論

流程概覽

flowchart LR
    A[Feature<br/>Freeze] --> B[Release<br/>Candidate]
    B --> C[QA 驗證]
    C --> D{Go / No-Go}
    D -->|Go| E[Production<br/>Release]
    D -->|No-Go| B
    E --> F[監控期]
    F --> G[覆盤]

    C -->|P0 Bug| H[Hotfix Path]
    H --> C

    style A fill:#FF9800,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#9C27B0,color:#fff
    style D fill:#F44336,color:#fff
    style E fill:#4CAF50,color:#fff
    style F fill:#009688,color:#fff
    style G fill:#607D8B,color:#fff
    style H fill:#F44336,color:#fff

文章概覽

在本篇文章中，您將學習到：

• Release 與 Deployment 的根本區別——為什麼這不是同一件事
• Release 完整生命週期的八大階段及其檢查清單
• Feature Freeze 的實務執行方式與例外處理流程
• QA 驗證的範圍、Bug 嚴重等級分類與 Go/No-Go 判定標準
• Staging 驗收的核心要點與 UAT 流程
• Go/No-Go 決策的 RACI 矩陣與決策框架
• Release Cadence 策略的選擇與適用場景
• Hotfix 的精簡流程與觸發條件
• 可直接套用的 Release Checklist 模板

---

為什麼需要 Release 方法論

Release 不等於 Deployment

這是許多團隊最常犯的認知錯誤：把 Release 和 Deployment 當成同一件事。

• Deployment（部署） 是一個技術動作——把程式碼從 A 搬到 B，讓它在新的環境上跑起來。這是 CI/CD pipeline 的工作，是工程師的日常操作。
• Release（發布） 是一個產品決策——決定什麼功能在什麼時間對什麼用戶可見。這涉及產品策略、市場時機、團隊準備度、風險評估。

一個成熟的團隊可以每天 deploy 數十次，但每兩週才 release 一次。Deploy 是把彈藥送上前線，Release 是決定什麼時候開火。Feature Flag 正是實現「deploy 與 release 解耦」的關鍵技術——程式碼已經部署在 Production，但功能對用戶不可見，直到你決定打開開關。

理解這個區別，是建立 Release 方法論的基礎。

沒有流程的 Release：Friday Deploy Horror Stories

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

沒有 Release 流程的團隊，常見的災難場景包括：

• 「反正 staging 上測過了」：Staging 環境跟 Production 配置不一致，部署上去才發現資料庫版本不同、環境變數缺少、第三方服務用了 sandbox key
• 「趕在下班前上」：沒有預留足夠的監控時間，出問題時人已經在捷運上
• 「rollback 應該很簡單吧」：有 database migration 但沒有寫 rollback script，回不去
• 「QA 說還有幾個 bug 但不嚴重」：上線後用戶發現那些 「不嚴重」 的 bug 恰好影響核心流程

Release 方法論解決的問題

結構化的 Release 方法論為團隊提供：

1. 可預測性：每個人都知道 Release 的時間表、流程和自己的角色
2. 品質保障：透過分階段的驗證，將問題攔截在 Production 之前
3. 風險控制：明確的 Go/No-Go 標準和 Rollback 計畫，降低上線風險
4. 責任歸屬：RACI 矩陣讓每個決策都有明確的負責人
5. 持續改善：Post-Release 覆盤讓每一次 Release 都比上一次更順暢

---

Release 的完整生命週期

一個完整的 Release 流程包含八個階段，從功能規劃到上線後監控，形成閉環：

flowchart LR
    A[Feature<br/>Planning] --> B[Development<br/>& Integration]
    B --> C[Code<br/>Freeze]
    C --> D[QA<br/>驗證]
    D --> E[Staging<br/>驗收]
    E --> F[Go/No-Go<br/>Decision]
    F --> G[Production<br/>Release]
    G --> H[Post-<br/>Release]

    style A fill:#4CAF50,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#FF9800,color:#fff
    style D fill:#9C27B0,color:#fff
    style E fill:#00BCD4,color:#fff
    style F fill:#F44336,color:#fff
    style G fill:#009688,color:#fff
    style H fill:#607D8B,color:#fff

每個階段都是下一個階段的前提條件。跳過任何一個階段，都會在後續階段產生更高的風險。以下逐一展開。

---

Phase 1：Feature Planning & Scoping

Release 的品質在規劃階段就已經決定了一半。一個範圍失控的 Release，無論後續流程多嚴謹，都很難順利上線。

Release Scope Definition

每一次 Release 都應該有明確定義的範圍（scope），回答以下問題：

• 這次 Release 包含哪些 Feature / User Story？
• 每個 Feature 的完成標準（Definition of Done）是什麼？
• 有哪些 Feature 之間存在依賴關係？（Feature A 必須先完成 Feature B 才能上線）
• 哪些 Feature 可以獨立 Release？（即使其他 Feature delay，也不受影響）

建議在 Sprint Planning 或 Release Planning 會議中，使用以下格式記錄 Release Scope：

# Release v2.5.0 Scope
 
## 必須包含（Must Have）
- [ ] FEAT-101：用戶資料匯出功能
- [ ] FEAT-102：訂單搜尋效能優化
- [ ] BUG-203：付款頁面金額計算錯誤修復
 
## 期望包含（Should Have）
- [ ] FEAT-104：通知中心改版
- [ ] FEAT-105：後台報表新增篩選器
 
## 可延後（Nice to Have）
- [ ] FEAT-108：深色模式支援
 
## 明確排除（Out of Scope）
- FEAT-110：多語系支援（移至 v2.6.0）

Feature Flag 策略

Feature Flag（功能開關）是實現「Deploy 與 Release 解耦」的核心機制。透過 Feature Flag，你可以：

• 提前部署，延後啟用：程式碼已經在 Production，但功能對用戶不可見，直到你決定開啟
• 漸進式發布：先對 1% 的用戶開啟，觀察指標，再逐步擴大到 100%
• 快速停損：如果新功能出問題，關閉 Feature Flag 比 rollback 整個 deployment 快得多
• A/B 測試：同時對不同用戶群體啟用不同的功能版本

Feature Flag 的生命週期管理同樣重要——一個 Feature Flag 在功能穩定上線後就應該被移除，避免程式碼中累積大量過期的 Flag 造成技術債。

依賴關係映射

在規劃 Release Scope 時，必須釐清 Feature 之間的依賴關係：

flowchart TD
    A[FEAT-101<br/>用戶資料匯出] --> C[FEAT-103<br/>匯出排程功能]
    B[FEAT-102<br/>搜尋效能優化] --> D[FEAT-106<br/>進階搜尋篩選]
    A --> E[BUG-205<br/>匯出格式修正]

    style A fill:#4CAF50,color:#fff
    style B fill:#4CAF50,color:#fff
    style C fill:#FFC107,color:#000
    style D fill:#FFC107,color:#000
    style E fill:#F44336,color:#fff

如果 FEAT-101 delay 了，FEAT-103 和 BUG-205 也會受影響。在規劃時就識別這些依賴，能讓團隊在做 scope 調整時有據可依。

Cut-off Date vs Scope 調整

Release 規劃中一個常見的張力是：時間固定還是範圍固定？

• 時間固定、範圍彈性（Time-boxed）：Release Train 模式。不管功能做到什麼程度，到日期就發車。沒趕上的 Feature 等下一班。這種模式適合需要可預測 Release 節奏的團隊。
• 範圍固定、時間彈性（Scope-based）：所有規劃的 Feature 都完成才 Release。這種模式常導致 Release 不斷延期，不建議採用。

建議採用 Time-boxed 模式，搭配 Must Have / Should Have / Nice to Have 的分級。 到了 cut-off date，Must Have 全部完成就可以 Release；Should Have 和 Nice to Have 沒完成就移到下一個 Release。

---

Phase 2：Development & Integration

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

分支策略對齊

開發期間的分支策略應與 Release 流程對齊。不同的分支管理模型有不同的適用場景，技術細節可參考 Release 管理 中的分支策略說明。以下是與 Release 流程相關的核心要點：

• Feature Branch：每個功能在獨立分支開發，完成後透過 Merge Request 合併到主開發分支
• Release Branch：在 Feature Freeze 時從主開發分支切出，作為 QA 和 Staging 驗證的基礎
• Hotfix Branch：從 Production 分支切出，用於緊急修復

持續整合的紀律

Daily Integration（每日整合）遠優於 Big-bang Merge（大爆炸式合併）。Big-bang Merge 是指所有 Feature Branch 在 Release 前才一次合併，這幾乎必然導致大量合併衝突和整合問題。

持續整合的紀律要求：

1. 小批量、高頻率：Feature Branch 的生命週期不應超過 3-5 天。如果功能太大，拆成可獨立合併的小單元
2. 每日 merge main 到 feature branch：保持 Feature Branch 與主線同步，避免分支漂移
3. CI Pipeline 門禁：所有 Merge Request 必須通過 lint、unit test、build 才能合併
4. 及時解決衝突：發現衝突立即解決，不要讓衝突累積

Developer Self-testing Checklist

在提交 Merge Request 之前，開發者應自行完成以下檢查：

## Developer Self-testing Checklist
 
### 功能驗證
- [ ] Happy Path 手動測試通過
- [ ] Edge Case 驗證（空值、極端值、邊界條件）
- [ ] 錯誤處理路徑驗證（API 回傳錯誤時 UI 的反應）
 
### 程式碼品質
- [ ] 單元測試覆蓋新增/修改的邏輯
- [ ] 沒有 TODO / FIXME / HACK 未處理
- [ ] 沒有 console.log / print 等除錯程式碼
- [ ] 命名清楚、程式碼結構合理
 
### 整合驗證
- [ ] 與相依的 API 端點整合測試通過
- [ ] Database Migration 可正確執行且可 rollback
- [ ] 環境變數有無新增？已更新部署文件
- [ ] Feature Flag 設定正確（如適用）
 
### 效能考量
- [ ] 新增的 DB Query 有合適的索引
- [ ] 沒有 N+1 Query 問題
- [ ] 大量資料情境下效能可接受

---

Phase 3：Code Freeze / Feature Freeze

Code Freeze（又稱 Feature Freeze）是 Release 流程中的關鍵分水嶺。它標誌著「新功能開發結束，進入穩定化階段」。

什麼是 Feature Freeze？

Feature Freeze 意味著：

• 不再合併新功能：所有未完成的 Feature 延後到下一個 Release
• 只接受 Bug 修復：且 Bug 修復也需要經過審查，確認是真的 bug 而非「順手加個小功能」
• Release Branch 切出：從主開發分支切出 Release Branch，後續所有修復都在這個分支上進行

Feature Freeze 不是停止所有程式碼變更。它是從「功能開發模式」切換到「穩定化模式」的分界點。

Feature Freeze 的時程

Feature Freeze 的持續時間取決於 Release 的規模和團隊的成熟度：

Release 規模	建議 Freeze 時長	說明
小型（1-3 個 Feature）	1 天	快速驗證即可
中型（5-10 個 Feature）	2-3 天	標準 QA 週期
大型（10+ Feature）	3-5 天	需要完整的 Regression Test
重大版本（架構變更）	5-7 天	需要深度測試和效能驗證

Feature Freeze 後允許的變更

明確定義 Freeze 之後什麼可以做、什麼不能做，避免 Freeze 形同虛設：

允許	不允許
QA 發現的 Bug 修復	新功能開發
文案、翻譯修正	「順便」改善的 UI 調整
關鍵效能問題修復	重構或程式碼「改善」
安全漏洞修復	非關鍵的依賴套件升級
阻塞性的技術問題修復	任何「很快就好」的小改動

Exception Process

如果 Freeze 之後確實需要加入變更（不在上表「允許」範圍內），必須走例外流程：

1. 提出申請：說明變更內容、原因、影響範圍
2. 風險評估：由 Tech Lead 評估此變更對 Release 穩定性的影響
3. 審批：由 Release Manager 或 Tech Lead 批准
4. 加強測試：此變更必須有額外的測試覆蓋
5. 記錄：記錄此例外，作為 Post-Release 覆盤的輸入

原則是：Freeze 後的每一個變更都應該被視為有風險的，除非有充分理由，否則預設答案是「不」。

Code Freeze Checklist

## Code Freeze Checklist
 
### 分支管理
- [ ] Release Branch 已從 develop 切出（如 release/v2.5.0）
- [ ] 所有預計包含的 Feature Branch 已合併到 Release Branch
- [ ] 未完成的 Feature Branch 已從 Release Scope 中移除
- [ ] Release Branch 的 CI Pipeline 全部通過
 
### 功能確認
- [ ] Release Scope 文件已更新（標記實際包含的功能）
- [ ] 所有 Must Have 功能已完成並合併
- [ ] Feature Flag 狀態已確認（哪些開、哪些關）
- [ ] Database Migration 檔案已包含在 Release Branch 中
 
### 團隊通知
- [ ] 開發團隊已被通知 Freeze 開始
- [ ] QA 團隊已收到 Release 範圍和測試環境準備指示
- [ ] Slack / 溝通頻道已發佈 Freeze 公告
 
### 文件
- [ ] API 變更已文件化
- [ ] 新增的環境變數已文件化
- [ ] Release Notes 草稿已開始撰寫

---

Phase 4：QA 驗證

QA 驗證是 Release 流程中的品質關卡。這個階段的目標是在程式碼到達 Production 之前，盡可能找出問題。

QA 測試範圍

QA 測試應涵蓋兩大區域：

1. 新功能測試：驗證本次 Release 包含的所有新功能和 Bug 修復是否符合驗收標準
2. 回歸測試（Regression Test）：驗證現有功能是否被新程式碼影響而出現問題

回歸測試的範圍取決於變更的影響面：

• 局部回歸：只測試與修改相關的模組和相鄰模組。適用於小型 Release
• 完整回歸：測試所有核心功能的 Happy Path。適用於大型 Release 或架構變更

測試環境要求

QA 測試環境應盡可能接近 Production 環境（參考 環境拆分）：

• 使用與 Production 相同版本的中介軟體（資料庫、Redis、Message Queue）
• 使用脫敏後的 Production 資料（而非空資料庫或少量測試資料）
• 使用與 Production 相似的環境變數結構
• 第三方服務使用 Sandbox 環境

Bug 嚴重等級分類

QA 過程中發現的 Bug 必須分類其嚴重等級，作為 Go/No-Go 決策的依據：

等級	定義	範例	Release 影響
P0 — Blocker	核心功能完全無法使用，無 workaround	無法登入、無法結帳、資料遺失	必須修復才能 Release
P1 — Critical	核心功能嚴重受損，有困難的 workaround	付款偶爾失敗、搜尋結果錯誤	強烈建議修復，否則需要 Release Manager 簽核風險
P2 — Major	非核心功能異常，或有簡單的 workaround	匯出報表格式錯誤、通知延遲	記錄為 Known Issue，可在下一版修復
P3 — Minor	細微問題，不影響功能使用	文字拼寫錯誤、間距不一致	記錄即可，不影響 Release 決策

Go/No-Go 標準（基於 Bug 嚴重等級）

條件	Go	No-Go
P0 Bug 數量	0	> 0
P1 Bug 數量	0（或已有 Release Manager 簽核的風險接受書）	> 0（且未經簽核）
P2 Bug 數量	已記錄為 Known Issue	不限制
P3 Bug 數量	不限制	不限制
回歸測試通過率	> 95%	< 95%
核心流程測試	100% 通過	任一未通過

QA Sign-off Process

QA 完成測試後，需要正式的 Sign-off（簽核）：

## QA Sign-off Report — Release v2.5.0
 
### 測試摘要
- **測試期間**：2024-09-10 ~ 2024-09-12
- **測試環境**：staging-v2.5.0
- **測試人員**：QA Team（Alice, Bob）
- **總測試案例數**：156
- **通過**：152
- **失敗**：4（已修復後 re-test 通過）
- **跳過**：0
 
### Bug 統計
| 等級 | 發現數 | 已修復 | 未修復 | 備註 |
|------|--------|--------|--------|------|
| P0 | 1 | 1 | 0 | JIRA-456：付款流程中斷 |
| P1 | 2 | 2 | 0 | |
| P2 | 3 | 1 | 2 | Known Issue，排入 v2.5.1 |
| P3 | 5 | 2 | 3 | 記錄在 backlog |
 
### 回歸測試結果
- 核心流程（登入、訂單、付款、通知）：**全部通過**
- 非核心流程：通過率 **97%**
 
### 簽核結論
- **Go / No-Go**：**Go**（所有 P0/P1 已修復，P2 已記錄為 Known Issue）
- **QA 負責人簽核**：Alice / 2024-09-12

---

Phase 5：Staging 驗收

Staging 驗收是 Release 上線前的最後一道防線。它的定位不同於 QA 環境的功能測試——Staging 驗收更關注「在接近 Production 的環境中，整體行為是否如預期」。

Staging 作為 Production 鏡像

Staging 環境的配置應盡可能與 Production 一致。關於環境分離的詳細設計原則，請參考 環境拆分。在 Release 流程中，Staging 環境需要特別注意：

• 部署方式與 Production 相同（同樣的 CI/CD pipeline、同樣的部署指令）
• 使用與 Production 結構一致的資料（脫敏後的生產資料或足量的種子資料）
• 第三方服務的 Sandbox 配置已正確設定
• SSL/TLS、DNS、Reverse Proxy 配置與 Production 一致

Stakeholder UAT（User Acceptance Testing）

UAT 是讓非技術的利害關係人（產品經理、業務負責人、客服主管）在 Staging 環境上進行最終驗收。UAT 的重點不是找 Bug（那是 QA 的工作），而是確認：

1. 功能行為符合需求規格：產品經理確認「做出來的東西就是我要的」
2. 使用者體驗可接受：操作流程順暢、畫面呈現合理
3. 業務規則正確：價格計算、折扣邏輯、權限控制等業務規則正確
4. 跨系統整合正常：與其他系統的串接（ERP、CRM、金流）運作正常

效能驗證

在 Staging 環境進行效能測試，確認新版本不會造成效能退化：

• 回應時間：核心 API 的 P95/P99 回應時間是否在 SLA 範圍內？
• 吞吐量：在預期負載下，系統是否能維持穩定的吞吐量？
• 資源消耗：CPU、Memory 使用率是否合理？有無 Memory Leak 跡象？
• 與前一版比較：新版本的效能指標是否優於或持平於當前 Production 版本？

Data Migration Dry-run

如果本次 Release 包含資料庫 Schema 變更或資料遷移：

1. 在 Staging 執行 Migration：確認 Migration 腳本可以正確執行
2. 計時：記錄 Migration 所需時間，評估對 Production 的影響（是否需要停機？）
3. 驗證資料完整性：Migration 後的資料是否正確？
4. 測試 Rollback：確認 Migration 可以成功回滾，回滾後資料是否完整

Staging 驗收 Checklist

## Staging 驗收 Checklist — Release v2.5.0
 
### 部署驗證
- [ ] Release Branch 已部署到 Staging 環境
- [ ] 部署過程無錯誤
- [ ] 所有服務健康檢查通過
- [ ] Database Migration 執行成功
 
### 功能驗收（UAT）
- [ ] 產品經理已完成核心功能驗收
- [ ] 業務負責人已確認業務規則正確
- [ ] 客服團隊已確認客服相關功能正常
- [ ] 跨系統整合測試通過
 
### 效能驗證
- [ ] 核心 API P95 回應時間 < [目標值] ms
- [ ] 壓力測試通過（[目標 QPS] QPS）
- [ ] 無 Memory Leak 跡象（24 小時穩定性測試）
- [ ] 效能指標與 Production 當前版本比較無退化
 
### 資料遷移（如適用）
- [ ] Migration Dry-run 成功
- [ ] Migration 耗時記錄：___ 分鐘
- [ ] Rollback 測試成功
- [ ] 資料完整性驗證通過
 
### 非功能驗證
- [ ] 日誌正確輸出，格式正確
- [ ] 監控指標正確上報
- [ ] 告警規則在 Staging 可觸發
- [ ] Feature Flag 開關狀態正確
 
### 簽核
- **產品經理**：_____ / 日期：_____
- **Tech Lead**：_____ / 日期：_____
- **QA Lead**：_____ / 日期：_____

---

Phase 6：Go/No-Go Decision

Go/No-Go Decision 是整個 Release 流程中最關鍵的決策點。這不是一個人的決定，而是基於前面所有階段的結果，由多方利害關係人共同做出的判斷。

RACI 矩陣

明確定義每個角色在 Go/No-Go 決策中的責任：

角色	R (Responsible)	A (Accountable)	C (Consulted)	I (Informed)
Release Manager	V
Tech Lead		V
Product Manager			V
QA Lead			V
Engineering Manager				V
客服 / 業務團隊				V

• R（執行者）：Release Manager 負責收集所有資訊、召開 Go/No-Go 會議、執行決策
• A（決策者）：Tech Lead 做最終的技術決策。如果技術上有風險，Tech Lead 有權叫停
• C（被諮詢者）：PM 和 QA Lead 提供功能和品質層面的意見
• I（被通知者）：Engineering Manager 和下游團隊被告知決策結果

決策標準 Checklist

Go/No-Go 會議中，逐項確認以下清單：

## Go/No-Go Decision Checklist
 
### 品質門檻
- [ ] P0 Bug：0 個
- [ ] P1 Bug：0 個（或已有風險簽核）
- [ ] 回歸測試通過率 > 95%
- [ ] 核心流程測試 100% 通過
- [ ] QA Sign-off 已完成
 
### Staging 驗收
- [ ] UAT 已完成且產品經理已簽核
- [ ] 效能驗證通過
- [ ] Data Migration Dry-run 通過（如適用）
 
### 準備度
- [ ] Rollback Plan 已就緒且已在 Staging 驗證
- [ ] 監控 Dashboard 已準備
- [ ] On-call 人員已排定
- [ ] Release Notes 已撰寫
- [ ] 內部溝通（Slack / Email）已準備
 
### 時機
- [ ] 不是週五下午
- [ ] 不在重大活動 / 促銷期間（除非這次 Release 就是為了該活動）
- [ ] Release Window 內有足夠的團隊人員在線
- [ ] 下游團隊（客服、業務）已被通知並準備就緒
 
### 決策
- **決策結果**：Go / No-Go / Go with conditions
- **如果 No-Go，原因**：_____
- **如果 Go with conditions，條件**：_____
- **決策者簽名**：_____ / 日期：_____

Rollback Plan 審查

在 Go/No-Go 會議中，Rollback Plan 必須被明確審查：

1. 觸發條件：什麼指標超過什麼門檻就觸發 Rollback？
2. 執行步驟：逐步的 Rollback 指令，任何 on-call 工程師都能執行
3. 資料回滾：如果有 Database Migration，回滾後資料如何處理？
4. 時間預估：預估 Rollback 需要多長時間？
5. 驗證方式：Rollback 完成後如何確認系統已恢復正常？

溝通計畫

Release 前的溝通計畫應涵蓋內部和外部兩個層面：

內部溝通：

• T-2 天：通知全體工程團隊 Release 時間和範圍
• T-1 天：通知客服團隊新功能說明和常見問題預備
• T-0（Release 時）：在 Slack Release 頻道即時更新進度
• T+1 小時：發送 Release 結果通知

外部溝通（如適用）：

• Release Notes 發布
• 用戶公告（重大功能上線時）
• API 變更通知（如有 breaking changes）

---

Phase 7：Production Release

當 Go/No-Go 決策為 Go，就進入實際的 Production Release 階段。

Release Window 選擇

選擇合適的 Release Window 能大幅降低風險：

時段	推薦度	原因
週二 ~ 週四上午	最佳	全團隊在線，有充足時間監控和處理問題
週一上午	可以	但週一早上通常有較多會議和待處理事項
週五	避免	出問題時可能需要週末加班處理
週末 / 假日	禁止	除非業務性質特殊（如遊戲版本更新、電商大促）
任何日的下午 4 點後	避免	出問題時已接近下班，處理時間不足

最佳 Release Window 範例：週二至週四，上午 10:00 - 12:00，確保下午有充足的監控時間。

部署策略

部署策略的技術細節已在 Release 管理 中詳述。從 Release 方法論的角度，需要根據風險等級選擇合適的策略：

策略	風險等級	適用場景	回滾速度
Rolling Update	低~中	常規 Release、無狀態服務	中（需要 rollback deployment）
Blue-Green	低	需要快速回滾的場景	極快（切換流量即可）
Canary	低	大型變更、不確定性高	快（停止金絲雀即可）

Feature Flag 啟用順序

如果本次 Release 包含需要透過 Feature Flag 啟用的功能，應規劃啟用順序：

1. 部署程式碼：所有 Feature Flag 預設為關閉
2. Smoke Test：確認部署成功且現有功能正常
3. 逐步啟用：按照優先順序和風險等級，逐一開啟 Feature Flag
4. 每個 Flag 開啟後觀察：等待 15-30 分鐘，確認指標正常後再開下一個
5. 如有異常：立即關閉該 Feature Flag，不需要 rollback 整個 deployment

Smoke Test Checklist

部署完成後，立即執行 Smoke Test 確認系統基本功能正常：

## Production Smoke Test Checklist
 
### 基礎設施
- [ ] 所有 Pod / Container 正常運行
- [ ] 健康檢查端點回傳 200
- [ ] 資料庫連線正常
- [ ] Redis 連線正常
- [ ] 第三方 API 連線正常
 
### 核心流程
- [ ] 首頁可正常載入
- [ ] 用戶可成功登入
- [ ] 核心 API 端點回應正常（[列出關鍵端點]）
- [ ] 關鍵業務流程可完成（[列出核心流程]）
 
### 監控確認
- [ ] Error Rate 無異常升高
- [ ] Response Time 在正常範圍
- [ ] CPU / Memory 使用率穩定
- [ ] 日誌無異常錯誤
 
### 結果
- **Smoke Test 通過**：是 / 否
- **如果未通過，採取行動**：___
- **執行人**：_____ / 時間：_____

---

Phase 8：Post-Release

Release 不是部署到 Production 就結束了。Post-Release 階段同樣重要，它涵蓋監控、驗證和覆盤。

監控期

Production Release 後，應進入監控期（Monitoring Period），持續關注系統狀態：

時間段	關注重點	行動
0-2 小時	立即影響	全團隊在線，密切監控所有指標
2-24 小時	短期穩定性	On-call 工程師持續監控，其他人可下線但保持可聯繫
24-72 小時	中期穩定性	On-call 正常輪值，關注趨勢變化

關鍵指標監控

監控期間應重點關注以下指標：

技術指標：

• Error Rate（錯誤率）：是否超出基線？
• Latency P95/P99（延遲）：是否有退化？
• Throughput（吞吐量）：是否異常下降？
• CPU / Memory 使用率：是否異常升高或有 leak 趨勢？
• Database 連線數 / 慢查詢數量

業務指標：

• 訂單數 / 交易量：是否異常下降？
• 用戶活躍數：是否有明顯流失？
• 轉換率：核心漏斗的轉換率是否受影響？
• 客訴數量：是否突然增加？

監控期間的事故回應

監控期間如果發現異常，應按照嚴重程度採取對應行動：

異常等級	觸發條件	行動
關注	指標輕微波動但在閾值內	持續觀察，記錄
警告	指標接近閾值	通知 on-call 工程師排查原因
嚴重	指標超出閾值	啟動事故流程（參考 事故管理），評估是否需要 Rollback
緊急	核心功能不可用	立即 Rollback，啟動 P1 事故流程

Release 覆盤（Retrospective）

每次 Release 後（無論成功或失敗），都應進行覆盤。覆盤不需要像 Post-mortem 那麼正式，但應記錄以下內容：

## Release Retrospective — v2.5.0
 
### 基本資訊
- **Release 日期**：2024-09-15
- **Release Manager**：David
- **規劃功能數**：8
- **實際發布功能數**：7（1 個延後至 v2.5.1）
- **Release 耗時**：2.5 小時（含監控期前 2 小時）
- **Rollback 次數**：0
 
### 做得好的地方
- Feature Freeze 按時執行，沒有例外申請
- QA 提前完成測試，留出充足的 Staging 驗收時間
- Smoke Test Checklist 完整，部署後 15 分鐘內確認完畢
 
### 需要改善的地方
- Migration Dry-run 只在 Staging 做了一次，建議至少做兩次
- Release Notes 在 Release 當天才開始寫，應該在 Freeze 時就開始準備
- 客服團隊在 Release 當天才被通知新功能，準備時間不足
 
### 行動項目
| # | 項目 | 負責人 | 到期日 |
|---|------|--------|--------|
| 1 | Release Notes 改為 Freeze 時開始草擬 | PM | 下次 Release |
| 2 | 客服通知提前到 T-3 天 | Release Manager | 下次 Release |
| 3 | Migration Dry-run 至少執行兩次 | DBA | 下次 Release |
 
### 指標追蹤
- Release 後 24 小時 Error Rate：0.05%（基線 0.04%，輕微上升但在可接受範圍）
- Release 後 24 小時 P99 Latency：180ms（基線 170ms，正常）
- 客訴數量：較前一週無明顯增加

Release Notes 生成

Release Notes 的受眾不同，內容深度也不同：

面向工程團隊（Internal Release Notes）：

• 技術變更清單（新增 API、Database Schema 變更、依賴升級）
• 已知問題（Known Issues）
• 環境變數或配置變更

面向產品 / 業務團隊：

• 新功能說明（附截圖或 GIF）
• Bug 修復清單
• 行為變更說明

面向終端用戶（External Release Notes）：

• 新功能亮點（用戶語言，非技術語言）
• 改善項目
• 已修復的問題

---

Release Cadence 策略

不同的團隊和產品，適合不同的 Release 頻率。選擇 Release Cadence 時需要考量團隊成熟度、產品性質和用戶期待。

策略	週期	適用場景	優勢	風險 / 挑戰
Continuous	每次 commit	SaaS 平台、內部工具	快速回饋、小變更低風險	需要非常成熟的 CI/CD 和自動化測試
Weekly	每週固定日	中型 SaaS、快速迭代產品	節奏穩定，變更量可控	需要嚴格的 weekly cut-off 紀律
Bi-weekly	與 Sprint 對齊	Scrum 團隊	與 Sprint 節奏自然對齊	最常見的選擇，平衡點佳
Monthly	每月一次	Enterprise / B2B 產品	充足的測試時間	單次 Release scope 大，風險集中
Release Train	固定時間，彈性 scope	大型團隊、多團隊協作	時間可預測，scope 可調整	SAFe 風格，流程較重

如何選擇？

• 團隊 < 5 人、產品初期：Weekly 或 Continuous
• 團隊 5-15 人、產品穩定期：Bi-weekly（與 Sprint 對齊）
• 團隊 > 15 人、多團隊協作：Release Train
• Enterprise / B2B、合約約束：Monthly

無論選擇哪種策略，都應避免「沒有節奏的 Release」——想到就 Release、PM 催了就 Release。 不可預測的 Release 節奏會讓團隊疲於奔命，也讓利害關係人無法規劃。

---

Release Checklist Template（完整版）

以下是一份可直接複製使用的完整 Release Checklist，涵蓋 Release 的全生命週期：

# Release Checklist — v[VERSION]
 
## Release 資訊
- **版本**：v[VERSION]
- **預計 Release 日期**：YYYY-MM-DD
- **Release Manager**：[NAME]
- **Release Scope 文件**：[LINK]
 
---
 
## Pre-Release（Release 前 3-5 天）
 
### Feature Freeze
- [ ] Feature Freeze 日期已通知團隊
- [ ] Release Branch 已切出
- [ ] 所有規劃功能已合併（或明確排除）
- [ ] Release Scope 文件已更新
 
### QA 驗證
- [ ] QA 測試計畫已準備
- [ ] 測試環境已部署最新版本
- [ ] 新功能測試完成
- [ ] 回歸測試完成
- [ ] 所有 P0/P1 Bug 已修復並 re-test
- [ ] QA Sign-off 已取得
 
### Staging 驗收
- [ ] Staging 環境已部署
- [ ] UAT 驗收完成
- [ ] 效能測試通過
- [ ] Data Migration Dry-run 通過（如適用）
- [ ] Staging 驗收簽核已取得
 
### Release 準備
- [ ] Rollback Plan 已撰寫
- [ ] Rollback 已在 Staging 演練
- [ ] Release Notes 已撰寫
- [ ] 監控 Dashboard 已準備
- [ ] On-call 人員已排定
- [ ] 客服團隊已被通知新功能
 
---
 
## Release Day（Release 當天）
 
### Go/No-Go
- [ ] Go/No-Go 會議已召開
- [ ] 決策結果：Go / No-Go / Go with conditions
- [ ] 決策者已簽核
 
### 部署執行
- [ ] 部署開始時間記錄：_____
- [ ] 部署過程無錯誤
- [ ] Database Migration 執行成功（如適用）
- [ ] 部署完成時間記錄：_____
 
### Smoke Test
- [ ] 健康檢查通過
- [ ] 核心功能 Smoke Test 通過
- [ ] Error Rate 無異常
- [ ] Response Time 正常
 
### Feature Flag 啟用（如適用）
- [ ] Flag 1：_____ — 已開啟 — 觀察 15 分鐘正常
- [ ] Flag 2：_____ — 已開啟 — 觀察 15 分鐘正常
- [ ] Flag N：_____ — 已開啟 — 觀察 15 分鐘正常
 
### 通知
- [ ] 內部 Release 公告已發送
- [ ] Release Notes 已發布
- [ ] 外部用戶公告已發布（如適用）
 
---
 
## Post-Release（Release 後 1-3 天）
 
### 監控
- [ ] 0-2 小時密集監控完成，指標正常
- [ ] 24 小時監控完成，指標正常
- [ ] 72 小時監控完成，指標正常
 
### 確認
- [ ] 客訴數量無異常增加
- [ ] 業務指標（訂單量、轉換率）無異常
- [ ] 無需 Rollback
 
### 覆盤
- [ ] Release Retrospective 會議已召開
- [ ] 覆盤記錄已撰寫
- [ ] 行動項目已建立在工作追蹤系統中
 
### 清理
- [ ] Release Branch 已合併回 main / develop
- [ ] Release Branch 已刪除
- [ ] 過期的 Feature Flag 已排定清理計畫

---

Hotfix vs Regular Release

並非所有 Release 都需要走完整的八個階段。Hotfix 是針對 Production 緊急問題的精簡版 Release。

什麼算 Hotfix？

Hotfix 的定義應該非常嚴格——只有 P0 等級的問題才走 Hotfix 流程：

算 Hotfix	不算 Hotfix
核心功能完全中斷（無法登入、無法付款）	非核心功能的 Bug
資料遺失或損毀風險	UI 顯示問題
安全漏洞（被利用中或即將被利用）	效能輕微退化
法規合規問題（罰款風險）	「很重要但不緊急」的 Bug

如果問題可以等到下一次 Regular Release 修復，那它就不是 Hotfix。

Hotfix 的精簡流程

Hotfix 流程是 Regular Release 的壓縮版，省略了部分步驟但保留核心的品質關卡：

flowchart LR
    A[識別<br/>P0 問題] --> B[Hotfix<br/>Branch]
    B --> C[修復 +<br/>Code Review]
    C --> D[精簡<br/>QA 測試]
    D --> E[快速<br/>Staging 驗證]
    E --> F[Deploy<br/>Production]
    F --> G[監控<br/>+ 覆盤]

    style A fill:#F44336,color:#fff
    style B fill:#FF9800,color:#fff
    style C fill:#FFC107,color:#000
    style D fill:#4CAF50,color:#fff
    style E fill:#00BCD4,color:#fff
    style F fill:#9C27B0,color:#fff
    style G fill:#607D8B,color:#fff

階段	Regular Release	Hotfix
Feature Planning	完整規劃	略（問題即 scope）
Development	按 Sprint 進行	立即修復（< 數小時）
Code Freeze	1-5 天	略
QA 驗證	完整測試	針對修復的功能 + 相關回歸
Staging 驗收	UAT + 效能	快速功能驗證
Go/No-Go	正式會議	Tech Lead 口頭確認
Production Deploy	計畫時間	盡快
Post-Release	72 小時監控 + 覆盤	24 小時監控 + 簡短覆盤

Hotfix 也要走流程，但是精簡版。 即使時間緊迫，也不能跳過 Code Review、不能跳過 Staging 驗證、不能跳過 Smoke Test。曾經有無數的案例證明：「緊急修復造成的二次事故」比原始問題更嚴重。

---

常見問題與反模式

在推行 Release 方法論的過程中，團隊經常遇到以下問題。識別這些反模式，有助於提前規避。

反模式一：「Release 就是 Deploy」

症狀：團隊把 Release 方法論等同於 CI/CD pipeline 配置。所有的討論都圍繞技術部署，沒有人關注「什麼功能應該在這次 Release 中」、「利害關係人是否同意上線」。

後果：功能上線後 PM 說「這不是我要的」、客服不知道有新功能上線、業務規則有誤但沒人驗收過。

解法：明確區分 Deployment（技術團隊的責任）和 Release（產品團隊的決策）。每一次 Release 都需要產品面和技術面的雙重確認。

反模式二：Feature Freeze 形同虛設

症狀：宣布 Freeze 後，PM 還是不斷要求加功能——「就加這一個小東西，很快就好」。工程師也默許，因為拒絕 PM 的要求很尷尬。

後果：Freeze 後加入的變更沒有經過充分測試，成為 Bug 的溫床。QA 的測試計畫被打亂，測試品質下降。Release 日期不斷往後推。

解法：

• Freeze 規則必須有管理層的支持和背書
• 設立正式的 Exception Process，讓 PM 知道不是「不能加」而是「要走流程」
• 追蹤 Freeze Exception 的數量，如果每次都有大量例外，說明規劃階段有問題

反模式三：QA 瓶頸

症狀：所有 Feature 在最後一天同時丟給 QA 測試。QA 時間被極度壓縮，只能做表面的測試。Bug 被遺漏到 Production。

後果：QA 成為 Release 流程的瓶頸，承受巨大壓力但又背負「沒測到 bug」的責任。Release 品質不穩定。

解法：

• QA 從開發階段就開始介入（Shift Left Testing）
• 功能完成一個就測一個，不要等到全部完成才開始
• 增加自動化測試覆蓋率，減少手動回歸測試的負擔
• 開發者的 Self-testing Checklist 是 QA 的前哨站

反模式四：沒有 Rollback Plan

症狀：Release 計畫中沒有 Rollback Plan，或者有 Plan 但從來沒有演練過。出問題時才發現 rollback script 跑不動、migration 回不去、Feature Flag 沒有設定。

後果：問題發生時手忙腳亂，MTTR（Mean Time To Recovery）極長，用戶影響範圍持續擴大。

解法：

• Rollback Plan 是 Go/No-Go 的必要條件——沒有 Rollback Plan 就不准上線
• 每次 Release 前在 Staging 環境演練 Rollback
• Database Migration 必須附帶 Rollback Script

反模式五：半夜 Release

症狀：團隊習慣在深夜或凌晨 Release，理由是「流量低、影響小」。

後果：工程師疲勞操作容易犯錯、判斷力下降；出問題時需要叫醒更多人支援；長期損害團隊健康和士氣。

解法：

• 如果系統需要停機 Release，應該透過 Blue-Green 或 Canary 策略實現零停機部署，而不是靠半夜低流量來規避風險
• 半夜 Release 只在極特殊情況下使用（例如跨時區的全球性服務，且沒有其他選擇）
• 正常情況下，選擇工作日上午的 Release Window

反模式六：Release Retrospective 虛應故事

症狀：每次 Release 後都說「要做覆盤」，但要嘛沒開會、要嘛開了會但沒有行動項目、要嘛有行動項目但沒人跟進。

後果：同樣的問題在每次 Release 中重複出現。團隊失去對覆盤的信心，覺得「開了也沒用」。

解法：

• 覆盤會議的行動項目必須進入工作追蹤系統（Jira / Linear / GitHub Issues）
• 指派明確的負責人和到期日
• 下一次 Release 的 Retrospective 第一項議程是「上次行動項目的執行狀況」

---

與其他文章的關係

本文從產品與流程的視角討論 Release 方法論。以下是相關文章的互補關係：

• 技術層面的部署操作：Release 管理 涵蓋分支策略、版本號管理、滾動部署 / 藍綠部署 / 金絲雀發布的技術實作
• 環境管理：環境拆分 詳述 Dev / Staging / Production 環境的設計原則，本文中的 Staging 驗收階段建立在正確的環境分離之上
• 事故回應：事故管理 中的 Runbook 和 Post-mortem 模板，適用於 Release 後的監控期間發生事故時
• 測試策略：測試策略 提供測試分層的完整指南，本文中 QA 驗證階段所需的測試類型和工具選擇可參考該文
• 系統規劃：系統規劃方法論 中的上線計畫（Phase 6），是本文 Release 方法論的上游輸入

---

小結

Release 方法論的核心不是流程的繁瑣，而是在正確的時間點做正確的檢查，確保每一次 Release 都是一個有意識的產品決策，而非一個碰運氣的技術動作。

八個階段的核心目標：

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

記住：好的 Release 應該是無聊的。 如果每次 Release 都像打仗一樣刺激，那說明你的流程有問題。當團隊能夠按照 checklist 平靜地完成 Release、從容地監控指標、然後收工下班——這才是 Release 方法論成功的標誌。

---

Proto 實踐對照

Proto 的 Release 策略：每個 Track 的 Proto 使用 Semantic Versioning（v{major}.{minor}.{patch}），Golden Version 確立後才延伸其他語言版本。CI/CD Pipeline 由 Infra 層統一管理，Proto 只需要提供 health check endpoint。詳見 Proto 規劃方法論 的版本管理策略。

---

延伸閱讀

• Release 管理：技術層面的分支策略、版本號管理與部署策略
• 環境拆分：Dev / Staging / Production 環境的設計與管理
• 事故管理：Release 後事故的 Runbook 與 Post-mortem 流程
• 測試策略：QA 驗證階段所需的測試分層與工具選擇
• 系統規劃方法論：從需求到上線的完整規劃流程