Release 週期
Release 週期通常由以下因素決定：
- Scrum 的 Sprint 設定
- PO/PM 決定的發布時程
Staging 環境流程
開發階段
- 在 development 建立 feature branch
- 開發完成後 code review
- Merge 進 development
- 累積功能後 merge 進 staging
驗證階段
假定每兩週做一次 release，流程如下：
- 產出 Changelog：在 development 產出（參考 泛用 Git 流程）
- 更新 Staging：Merge development 到 staging
- 通知團隊：在公用群組通知 staging 已更新，請 PO/QA 進行測試
驗證結果處理
| 情況 | 處理方式 |
|---|---|
| 測試通過 | 開 release branch → 打 tag → 對 master 發 MR |
| 發現問題 | 修復 → 更新 development → 重新 merge staging → 再次驗證 |
Production 環境流程
發布前準備
負責 master 更新的人需要有：
- 已測試通過的 release branch
- 這次進版的 changelog
發布流程
- 取得授權：通知產品負責人與資訊負責人，說明更新內容
- 執行更新：如果有 CD 會自動完成
- 通知團隊：更新完畢，開始線上監控
問題處理機制
T0 等級問題
頁面崩潰、無法結帳等重大問題：
- 召開跨部門線上會議
- 每 30 分鐘回報修復狀態
- 若 1 小時內無法修復 → 考慮退版
- 若 1 小時內修復 → 走完驗證流程後上線
非 T0 等級問題
- 當天內走完驗證流程並更新
- 或併入下次更版處理
退版流程
真的需要退版時：
- 在 master 上 checkout 上一個 tag
- 觸發 deploy 動作
- PO/技術負責人 review 退版原因
避免退版的技巧
開發時加入 Feature Flag（功能開關），上版有問題時直接關閉開關，不需要退版。
上線後監控
- 確認服務正常運作
- 定期檢視 APM 系統
- 收集問題並安排修復