Release 管理：確保版本穩定的流程

分支管理是手段，把穩定的程式碼交付給使用者才是目的。

先講結論

Release 管理就是「怎麼把程式碼安全地部署到生產環境」。核心概念：定期發佈、語義化版本號、自動化測試、永遠有回滾方案。沒有回滾計畫的發佈就是在賭博。

Release 流程

flowchart LR
    A[需求收集] -->|優先排序| B[版本規劃]
    B --> C[開發與測試]
    C -->|建立 Release 分支| D[發布準備]
    D -->|合併到 master| E[正式發佈]
    E --> F{出問題了？}
    F -->|是| G[回滾]
    F -->|否| H[版本穩定]

    style E fill:#4CAF50,color:#fff
    style G fill:#f44336,color:#fff

從需求收集到正式發佈，每一步都有明確的檢查點。重點不是流程多漂亮，而是出問題時你有方案。

SemVer：版本號不是亂編的

主版本.次版本.修補版本，例如 2.1.3：

• 主版本：有破壞性變更（不向下相容）
• 次版本：新增功能（向下相容）
• 修補版本：修 bug

看到版本號從 1.9.0 跳到 2.0.0，你就知道有 breaking change 了。好的 commit message 規範（CommitLint）可以讓自動生成 Release Notes 變得更容易。

三種部署策略

滾動發佈（Rolling Release）：逐步部署到不同節點，系統不停機。適合有多台伺服器的架構，但需要複雜的部署管理。

藍綠部署（Blue-Green）：兩套一模一樣的環境，新版本部署到備用環境，測試通過後切換流量。回滾就是切回去，像翻開關一樣簡單。缺點是要多養一套環境。

金絲雀發佈（Canary Release）：先讓一小部分用戶用新版本，觀察沒問題再全面部署。就像煤礦裡的金絲雀 — 先讓少數人「試水溫」。需要精細的流量控制。

回滾：你的保險

回滾策略必須在發佈前就準備好，不是出事了才想：

• 版本回滾：直接退回上一個穩定版
• Hotfix 分支：從 master 開出來修復，合回 master + develop
• Feature Flag：開發時加入功能開關，上線有問題直接關掉，不需要退版。這招超好用

自動化工具

• GitHub Actions / GitLab CI/CD：自動化測試和部署
• Jenkins：複雜的 CI/CD 流程配置

哪個好？看你的團隊用什麼平台。重點不是工具，是你有沒有把流程自動化。

---

Release 管理聽起來很無聊，但它是讓你週五晚上能安心下班的關鍵。不然你就是那個半夜被 call 回滾的人。

---

參考資源

• 語義化版本控制（SemVer）

延伸閱讀

• Git Flow — 完整的分支管理模型
• GitHub Flow — 簡潔的分支管理策略
• GitLab Flow — 靈活的分支管理策略
• Release 流程 — 更具體的 release 操作步驟
• CommitLint 規範 — commit 訊息規範