FSTS 版本開發生命週期與 CI/CD Pipeline
OMS 專案（.NET 8 + Docker + GitHub Actions）從需求到 Production 的端到端流程，以及背後的 CI/CD Pipeline 組件。回到 FSTS 專案總覽，相鄰規範：後端編碼規範、前端編碼規範。
一句話
OMS 採「push 即部署」模式：push 程式碼 → GitHub Actions 跑測試並 build Docker image → 推到 GHCR → Watchtower 自動偵測並更新容器；整條流程由 六大關鍵節點 把關（需求建立 → 開發分支 → CI Pipeline → AI Code Review → UAT 驗證 → Production 部署）。12
六大關鍵節點總覽
| # | 節點 | 把關方式 | 是否需人工 |
|---|---|---|---|
| 1 | 需求建立 | PM / PO 確認範圍 | ✅ |
| 2 | 開發分支 | feature/* / fix/* + AI 輔助 | ✅ |
| 3 | CI Pipeline | Lint → Build → Test → Security Scan → Quality Gate | 自動 |
| 4 | AI Code Review | 🔴 Must Fix = 0 才可合併 | 自動 |
| 5 | UAT 驗證 | Watchtower 自動部署 + PM/QA 驗收 | ✅ |
| 6 | Production 部署 | AI Review + 人工 Review（≥ 1 Approve）+ Environment Gate | ✅ |
把關分層：進 UAT 由「CI + AI Review」自動把關，不需人工審核可快速迭代；進 Production 則要「AI Review + 人工 Review」完整審查後才上線。34
端到端流程摘要
開發 feature/* / fix/* → git push
│
CI Lint → Build → Test → Security Scan → Quality Gate
│
AI 審查 AI Code Review（🔴 Must Fix = 0）
│
UAT 自動合併 → Watchtower 部署 → PM / QA 驗收
│
審核 AI Review + 人工 Review（1 人 Approve）
│
上線 Environment Gate → Push :latest → Health Check
▼
v{X.Y.Z} 上線完成
節點 1–2：開發 → CI 自動驗證
開發分支（節點 1–2）：6
- 建立
feature/*或fix/*分支 - 開發者自行決定 AI 輔助程度
- 撰寫程式碼 + 單元測試
git push觸發 CI Pipeline
CI Pipeline：
- Lint & Format Check
- Build（Docker multi-stage）
- Unit / Integration Tests
- 安全掃描：CodeQL、Gitleaks、Trivy
- Quality Gate 判定
節點 3–4：AI Code Review → UAT 驗證
AI Code Review：由工具檢查 7
- 程式邏輯 & 潛在 Bug
- 架構一致性 & 命名規範
- 安全性審查
- 測試充分性評估
- 🔴 Must Fix = 0 才可合併
UAT 驗證環境：
- PR →
uat自動觸發 - Watchtower 自動部署
:uatimage - PM / PO 功能驗收
- QA 測試（手動 + 自動）
- 效能測試（若有重大變更）
- 通過 → 建立 PR:
uat → prod
節點 5–6：人工審核 → Production 部署
人工 Code Review：8
- PR:
uat → prod觸發 - 查看 AI Review 報告
- 程式碼 Diff 審查
- 商業邏輯正確性
- UAT 驗收結果確認
- 至少 1 人 Approve
Production 部署：
- Merge to
prod→ CD Pipeline - Environment Gate（人工 Approve）
- Push
:latest→ GHCR - Watchtower 自動拉取更新
- Health Check 驗證
- 上線後監控（至少 30 分鐘）
CI / CD 分工
兩個完全獨立的 workflow：9
| 面向 | CI | CD |
|---|---|---|
| 觸發 | 開 PR 到 main/uat | Push 到 prod/uat |
| 內容 | Unit + Integration + API Test | Test → Build Image → Push GHCR |
| 目的 | 驗證 PR 品質 | 打包發佈 image |
環境對應與 Watchtower 自動部署
| 環境 | 分支 | Image tag |
|---|---|---|
| Production | prod（由 main 合入） | latest |
| UAT | uat | uat |
Watchtower 每 60 秒 檢查 GHCR，偵測新版 → 自動拉取 → 重啟容器；merge PR 到 main 後約 2–3 分鐘 Production 即自動更新。10
每次 build 都會附帶 commit SHA tag（例 oms-api:a1b2c3d），確保可精確回滾。
回滾機制 SOP
出問題時：11
- 停掉 Watchtower：
docker stop watchtower - 指定版本重建容器：用 commit SHA tag 啟動舊版
- 確認穩定後恢復：
docker start watchtower
安全重點
- 敏感設定不進 Git：DB 連線字串、JWT Secret 放 VM
/opt/oms/目錄，透過 Docker volume mount - 檔案權限控管：設定檔
chmod 600，只有擁有者可讀寫 - SSH Key Only：禁用密碼登入，只允許 SSH Key 認證
- 最小權限原則：GitHub PAT 只給
read:packages權限
相關頁面
- FSTS 後端編碼規範 — Clean Architecture + CQRS + MediatR 細則
- FSTS 前端編碼規範 — Feature-based + 三層狀態管理
- FSTS 系統架構 — 前後端 + 部署拓樸
- FSTS Git 衝突報告 — merge 衝突處理歷史
- FSTS 專案總覽 — 專案入口
補充資訊
(未來 ingest 新來源會在此追加段落)