Release Gate Layering¶
概念概覽
問題根因¶
核心知識¶
問題根因¶
當 Production Gate 把所有阻擋條件都標為 P0，會發生「P0 通膨」—— 所有條件看起來同等重要，實際決策時沒有真正的優先級，最終要麼全卡、要麼全放行。
兩層架構¶
Release Minimum（4-5 個）
↳ 真正決定「能不能發版」的 blocker
↳ 任一未過 → 絕對不發版
↳ 例：migration 跑通、auth 服務可用、crash rate < X%
Full Production Gate（完整清單）
↳ 理想發版狀態的全部條件
↳ 用於追蹤和計畫，不強制阻擋
↳ 可以帶著已知 gap 發版（附 mitigation plan）
設計原則¶
- Release Minimum 條目數要嚴控（4-5 個），不能因為「都很重要」就一直加
- 新條件優先進 Full Gate，只有真正的 P0 blocker 才升入 Minimum
- Minimum 的條件應該是**可機械化驗證**的（CI 跑過、metrics 在範圍內），不能是主觀判斷
經驗教訓¶
-
P0 通膨讓 release gate 失去意義，必須強制限制 Minimum 條目數
-
Release Minimum 條件應可機械化驗證，不能是主觀判斷
-
Full Gate 用於追蹤計畫，不是強制阻擋
常見陷阱¶
-
把所有重要條件都標 P0 導致優先級平鋪失效
-
Release Minimum 條目數持續增長沒有上限
-
用主觀「感覺準備好了」作為 Minimum 條件
最佳實踐¶
-
Release Minimum 嚴控 4-5 個真正 blocker
-
新阻擋條件預設進 Full Gate，需要明確決策才升入 Minimum
-
Minimum 條件要可以用 CI/metrics 機械化驗證
相關概念¶
- ci-gate-contract----dangling---
- golang-migrate Transaction Safety Contract
- TestBot Anti-Drift Strategy
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Production Readiness Audit Methodology — 共享：
production-readiness/ 獨特：1m-ccu,audit - Go Microservice Production Readiness Scoring — 共享：
production-readiness/ 獨特：1m-ccu,audit - Go Unbounded Goroutine Anti-Pattern — 共享：
p0/ 獨特：concurrency,goroutine - JIT Blind-spot Testing — 共享：
production-readiness/ 獨特：integration-test,microservices
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-30 | 45cbfb38-30e4-4de0-9d9c-1ea02a62e945 | 提出 Release Gate 應拆成兩層（Release Minimum vs Full Production Gate）以防止 12 個 P0 平鋪導致優先級失效 |