[git] Release 流程

Release 不是按個按鈕就好的事 — 從驗證到上線到出事怎麼辦，每一步都要想清楚。

先講結論

Release 流程的核心：staging 驗證通過 → 開 release branch → 打 tag → 合進 master → 上線監控。出問題？T0 等級一小時內修不好就退版，非 T0 併入下次更版。Feature Flag 可以讓你不退版就關掉有問題的功能。

Staging 驗證

Release 週期通常由 Sprint 設定或 PM 決定。假定每兩週 release 一次：

# 1. 在 development 產出 changelog
npm run changelog
 
# 2. Merge development 到 staging
git checkout staging
git pull
git merge development
 
# 3. 通知團隊：staging 已更新，請 PO/QA 測試

測試通過？開 release branch、打 tag、對 master 發 MR。發現問題？修復後重新走一次。

Production 上線

負責 master 更新的人需要：已測試通過的 release branch + 這次進版的 changelog。

# 開 release branch 並打 tag
git checkout -b release/20230519
git tag -a "v1.0.2" -m "add commit lint, changelog function"
git push -u origin release/20230519
# 對 main 發 MR

上線流程：通知產品和資訊負責人 → 執行更新（有 CD 就自動完成）→ 通知團隊開始線上監控。

出事了怎麼辦？

T0 等級（頁面崩潰、無法結帳）

1. 召開跨部門線上會議
2. 每 30 分鐘回報修復狀態
3. 1 小時內修不好 → 退版
4. 1 小時內修好 → 走完驗證流程後上線

非 T0 等級

• 當天內走完驗證流程更新，或併入下次更版

退版操作

# 在 master 上 checkout 上一個 tag
git checkout v1.0.1
# 觸發 deploy

PO 和技術負責人必須 review 退版原因。退版不丟臉，硬撐才丟臉。

Feature Flag：不退版的解法

開發時加入功能開關，上線有問題時直接關閉開關，不需要退版。

這招在實務上超好用。把新功能包在 flag 裡面，出問題關掉就好，使用者完全無感。

上線後監控

1. 確認服務正常運作
2. 定期檢視 APM 系統
3. 收集問題並安排修復

---

Release 做得好，你週五晚上就能安心追劇。做不好？那你週五晚上就追 error log 吧。

---

延伸閱讀

• 泛用 Git 流程及對應指令
• CD 持續整合與持續部署
• Release 管理 — 更完整的 Release 策略