近期前端職缺除了框架，也很重視工程師能不能把功能穩定送到正式環境。
面試可能會問：
- PR 建立後 CI 應該跑什麼？
- merge、rebase、squash 差在哪？
- 正式環境發生白畫面怎麼查？
- source map 要不要公開？
- 如何降低部署風險？
一個基本的前端 CI Pipeline
Pull Request
→ install with lockfile
→ lint
→ type-check
→ unit / integration test
→ production build
→ preview deployment
→ E2E smoke test
→ review / merge越便宜、越快的檢查放越前面，讓錯誤提早失敗。
為什麼一定要用 lockfile？
CI 應使用：
npm ci而不是任意更新 dependencies。
lockfile 讓本機、CI、production 安裝相同版本，也讓 dependency cache 更穩定。
PR 階段要檢查什麼？
基本 quality gates：
- formatting / lint
- TypeScript type-check
- unit / integration tests
- production build
- bundle size 變化
- dependency security scan
- 核心 E2E smoke tests
不是每個專案都要全部阻擋 merge，但應依風險設定必要條件。
Merge、Rebase、Squash
Merge
保留 branch 歷史和 merge commit，脈絡完整，但 graph 可能較複雜。
Rebase
把 commit 重新接到最新 base 上，歷史線性，但會重寫 commit hash。已共享的 branch 要小心。
Squash Merge
把 PR 多個 commit 合成一個，主分支乾淨，但細部 commit 歷史會被壓縮。
面試不需要宣稱哪個一定最好，重點是理解團隊 workflow 和重寫歷史的影響。
Preview Deployment 的價值
每個 PR 建立獨立 preview URL，可以讓：
- PM / Designer 提前驗收
- QA 測試真實 build
- 跑瀏覽器 E2E
- 比較 RWD 和互動
- 在 merge 前發現環境差異
但 preview 仍要避免連到 production 資料或暴露 secret。
正式環境白畫面怎麼排查？
我會依序確認：
- 影響範圍：所有人、特定瀏覽器、特定 route？
- 最近部署：是否和 release 時間吻合？
- Browser console：JavaScript runtime error？
- Network：JS chunk 404、API 401/500、CORS？
- Error tracking：stack trace、release、user context
- Source map：還原壓縮後程式碼位置
- 必要時 rollback 或關閉 feature flag
先止血，再找根因。
Source Map 怎麼使用？
Production bundle 會壓縮，stack trace 可能只看到：
app-9fd31.js:1:28491Source map 可以還原到原始 TypeScript 檔案與行號。
實務上可以把 source map 上傳到 error tracking 平台，但不一定要公開提供給所有使用者下載，以避免暴露過多原始碼資訊。
前端要監控什麼？
Errors
- uncaught exception
- unhandled rejection
- API failure rate
- resource load error
Performance
- LCP
- INP
- CLS
- route transition time
- API latency
Product Signals
- 登入成功率
- 結帳成功率
- 關鍵按鈕完成率
- 特定版本的異常比例
只有 console.log 不足以處理 production 問題。
如何降低部署風險？
- small PR / small release
- feature flag
- canary / gradual rollout
- preview environment
- automated smoke test
- rollback strategy
- DB / API backward compatibility
- release monitoring
前端也要注意舊 HTML 引用新舊 chunk、CDN cache 和 service worker 更新問題。
常見追問
CI 和 CD 差在哪？
CI 是持續整合，確保每次變更能建置與驗證；CD 可以指持續交付或持續部署，負責把通過驗證的版本送到可發布或正式環境。
Build 成功就代表可以上線嗎？
不代表。還要確認 runtime env、API contract、權限、瀏覽器行為、migration 和核心流程。
發生事故時先修還是先 rollback？
看影響程度。如果影響核心流程或大量使用者，通常先 rollback / feature flag 止血，再分析根因和補測試。
面試回答模板
我的前端 CI 會先跑 lint、type-check、unit/integration test 和 production build，再建立 preview deployment，核心流程用 E2E smoke test 驗證。正式環境發生問題時，我會先確認影響範圍和最近 release，從 error tracking、source map、Network、console 和 Web Vitals 定位；嚴重事故先 rollback 或關閉 feature flag。修復後會補 regression test 和監控，避免只修表面症狀。