流程定位

前端部署的風險集中在 build time。後端服務可以在 runtime 讀取設定、檢查資料庫與逐步接流量；前端靜態產物多半在 build 階段就把 route、asset path、環境變數與 feature flag 預先寫入 bundle。CI/CD 的判讀重點因此是「被部署的 artifact 是否就是已驗證的那一份」。

Build 階段負責建立可驗證產物。真實服務裡，npm run dev 成功不代表 production build 能成功；CI 應固定 Node 版本、package manager、lockfile、build command 與必要環境變數，讓 artifact 可以從乾淨環境重建。

Browser test 階段負責驗證使用者實際會看到的頁面。Playwright、visual diff、a11y check 或 smoke test 應盡量對 build 後的靜態站執行，避免 dev server 的 fallback、熱更新或寬鬆路由遮蔽 production 問題。

Preview environment 階段負責把 PR 變成可操作畫面。Preview URL 要能追到 PR、commit 與 workflow run，reviewer 才能把畫面問題回報到正確版本；preview 也要隔離 production 資料與 credential，避免預覽環境變成未受控入口。

Deploy 階段負責把 artifact 放到 hosting 或 CDN。前端部署失敗常出現在 cache policy、SPA fallback、base URL、static route 與 sourcemap 權限；deploy 成功只代表檔案上傳完成，仍需要檢查入口頁、核心路由與 asset 是否能從公開網址載入。

Rollback strategy 階段負責恢復上一份可用靜態產物。前端 rollback 表面上只是切回舊檔案，但若 API schema、build time config 或 CDN cache 已經變動，舊頁面仍可能呼叫不相容的後端，因此 rollback 要搭配 smoke test 與 cache purge。

常見失敗路由

前端 CI 紅燈要先判斷失敗在 build、browser test、preview 還是 production deploy。不同層的修復入口不同；把所有紅燈都當成「重跑 workflow」會掩蓋 artifact 漂移與 cache 問題。

這張表的用途是縮短定位時間。前端部署問題常被誤判成「CDN 壞掉」或「瀏覽器快取」，但更常見的根因是 build artifact、route 與 cache policy 的契約沒有明確寫進 pipeline。

最小 workflow 骨架

前端 workflow 應把 build、test、preview 與 deploy 的資料流顯性化。下面是概念骨架，重點在 artifact handoff 的方向，特定平台語法是次要的。

 1jobs:
 2  build:
 3    steps:
 4      - run: npm ci
 5      - run: npm run build
 6      - uses: actions/upload-artifact
 7        with:
 8          name: web-dist
 9          path: dist
10
11  test:
12    needs: build
13    steps:
14      - uses: actions/download-artifact
15        with:
16          name: web-dist
17      - run: npm run test:e2e:static
18
19  preview:
20    needs: test
21    if: github.event_name == 'pull_request'
22    steps:
23      - uses: actions/download-artifact
24        with:
25          name: web-dist
26      - run: npm run deploy:preview
27
28  deploy:
29    needs: test
30    if: github.ref == 'refs/heads/main'
31    steps:
32      - uses: actions/download-artifact
33        with:
34          name: web-dist
35      - run: npm run deploy:production

這個骨架讓 deploy 依賴 test，也讓 test 與 deploy 使用 build job 產生的同一份產物。若專案需要在不同環境注入設定，要明確區分 build time config 與 runtime config，避免同一份 artifact 被重新 build 成另一份內容。

Tripwire

Tripwire 的責任是提醒前端 workflow 需要重切。當同一類問題反覆出現，局部補命令通常只能暫時遮住資料流錯位。

• Preview 常和 production 不一致：把 preview 改成部署 build artifact，讓 preview job 沿用同一份產物。
• E2E 測試通過但 production 壞：把 E2E 改到 static artifact 或 production-like server 上執行。
• rollback 依賴人工找舊 commit：保留 release artifact 與版本索引，讓回退指向明確產物。
• CDN cache 問題反覆出現：把 HTML cache、asset cache 與 purge 策略寫進 deploy checklist。

下一步路由

• 前端部署總覽：回 前端部署 CI/CD。
• Gate 原理：讀 CI gate 與 workflow 邊界。
• 本 blog 靜態站案例：讀 本 blog 專案部署。

概念位置

Preview Environment 位在 pull request workflow 與正式部署流程之間，常由臨時 URL、隔離資源與到期清理組成。

可觀察訊號

• 團隊需要在合併前驗證 UI、路由或互動行為。
• 單靠測試報告不足以判斷體驗差異。
• 變更常包含環境變數、CDN 設定或靜態資產路徑。

接近真實服務的例子

前端 PR 自動建 preview URL 給 reviewer 驗證。後端則可能建立 review app 供 API 與整合測試使用。

設計責任

Preview Environment 要定義建立條件、資源上限、可見範圍與清理策略，避免成本與風險失控。