01 · 上版約定與分支範本

文件版號 v2026100501 · 分兩層：必須遵守的上版約定（對 SRE），以及各團隊可以採用、調整或不用的分支範本。 · 互動原版 ↗

Part A — 上版約定（必須遵守）

1. 每個 repo 每次上版一位 Release Manager，不管有幾個團隊或部門參與。Release Manager 整合這個 repo 所有的 MR 與上版細節，是 SRE 唯一的窗口。一次上版牽涉多個 repo 時，由這些 repo 的 Release Manager 排定一份 release plan（哪些 repo、順序、各自退回哪一版）。
2. 期限： tag + 完整 commit hash + release plan 要在 release day 前一個工作日下班前交給 SRE。超過就排到下一個 release day。
3. 每個 repo 每次 release day 只有一個 tag。 MR 在打 tag 之前全部合完。
4. Release day： 灰度（真實流量）11:00 開始、14:00 終止，時段內可以 n 次，每次都是整組。任一 repo 有問題 → SRE 把整個 release 從灰度撤回；每位 Release Manager 重新交付 tag + hash，整組重上灰度。14:00 灰度終止 — 還在進行的那一輪停止，沒通過的 release 延到下一個 release day。通過灰度的那一組依 release plan 順序上 production（可以在 14:00 之後）。
5. 部署前核對 tag ↔ hash；對不上就不上。
6. 能退版或有開關，在申請中寫明。兩者都沒有，SRE 照上，出事由開發往前修。
7. 退版： SRE 依 release plan 反向，對每個 repo 重新部署上一版（整個 release 一次全退），或把開關關掉。當天要不要再上由 Release Manager 決定；整組重新交付，並在 14:00 前通過灰度。
8. Hotfix 只限有產生客訴事件、造成帳務或金流問題、系統效能優化的修正。Release Manager 附依據提出、SRE 確認，交付方式一樣是 tag + hash，先灰度再 production。
9. 界線： repo 內部的版控錯誤（tag 打錯、分支起點錯、合併出錯）由開發處理。SRE 部署的就是交付的東西。

角色

角色	層級	負責
Release Manager（開發）	約定	每個 repo 每次上版一位；整合 MR 與上版細節；前一工作日交付 tag + hash；提出 hotfix 與只改設定的上版。
SRE	約定	核對 tag ↔ hash；先灰度再 production；從灰度撤回；退版；確認 hotfix 條件；凍結期。不在 app repo 裡合併、開分支或打 tag。
開發人員、開發主管	範本	團隊內的開發、審核與決定要上什麼。
QC	範本	選用、未來的步驟：交付前驗收 rc。

Part B — 分支範本（建議做法）

圖 3 — 分支線示意：release/1.4.0 在前一工作日之前切出，收進兩個團隊的功能；rc.1 在前一工作日交付，灰度沒過，整個 release 撤回；修正後的 rc.2 重新交付，在 14:00 前通過灰度並上 production；之後的 hotfix 從 master 開、合進 release，rc.3 經灰度上 production；所有 repo 驗證正常後，Release Manager 把 release 合進 master 並打 v1.4.0。

• feat/* 從 master 開；release/X.Y.Z 在前一工作日之前從 master 切出；要上的功能用 MR 合進來；Release Manager 打 vX.Y.Z-rc.N 並交付。
• 灰度沒過時，在原本的 feat/* 上修、再合一次，重新交付新的 rc，必須在 14:00 前通過灰度。
• production 驗證後，Release Manager 把 release/X.Y.Z 合進 master，打正式 tag vX.Y.Z。
• Hotfix 分支做法：情況 A（release 已上 production、還沒合進 master）— 從 master 開 hotfix/*，MR 進 release，打新 rc。情況 B — 在 hotfix 分支打 rc，上 production 後合進 master。
• 不用 cherry-pick；squash 只用在 feat/* 或 hotfix/* → release/*。功能開關讓功能之後用只改設定的上版打開。