CI/CD 核心概念
為什麼需要 CI/CD？
傳統開發流程：
寫程式 → 手動測試 → 手動 FTP → 手動重啟 → 發現忘記改 config → 重來
CI/CD 流程：
推送程式碼 → 自動測試 → 自動建置 → 自動部署 → 自動通知
Vibe Prompt
「請幫我畫出 CI/CD 流程圖，並解釋每個階段的用途。」
核心術語
- CI (Continuous Integration)：頻繁合併程式碼，每次合併自動建置與測試
- CD (Continuous Deployment)：通過測試後自動部署到生產環境
- Pipeline：從程式碼到生產環境的自動化流程
- Artifact：建置產出物（Docker Image、.next 資料夾等）
本日總結
- CI/CD 解決「在我電腦可以跑」的問題
- CI = 自動建置+測試，CD = 自動部署
關鍵要點
- ✅ CI (持續整合) = 頻繁合併程式碼 + 自動建置 + 自動測試
- ✅ CD (持續部署) = 通過測試的自動部署到生產環境
- ✅ CI/CD Pipeline 的核心：Build → Test → Deploy
- ✅ GitHub Actions + Docker = 最受歡迎的 CI/CD 組合
- ✅ 好 CI/CD 的標準：快、可靠、可重現
關鍵指標
| 指標 | 目標 | 意義 | |------|:----:|------| | Pipeline 時間 | < 10 分鐘 | 開發者等待時間越短越好 | | 部署頻率 | 每天多次 | 越小批次的部署風險越低 | | 失敗恢復時間 | < 1 小時 | 出錯後能快速回退 | | 變更失敗率 | < 15% | 部署到生產後的故障率 |
部署策略深入比較
藍綠部署 (Blue-Green Deployment)
維護兩套完全相同的環境（Blue = 當前版本，Green = 新版本）。 切換時只需調整 Load Balancer 的流量指向：
使用者 → Load Balancer ──▶ Blue (v1.0, 當前)
└─▶ Green (v2.0, 新版本，待命)
# 切換瞬間：
使用者 → Load Balancer ──▶ Blue (v1.0, 保留)
└─▶ Green (v2.0, 當前) ✅
| 優點 | 缺點 | |------|------| | 切換瞬間完成，無停機時間 | 成本加倍（需要兩套完整環境） | | 快速回退（一秒切回 Blue） | 資料庫結構變更需要相容性 | | 可以先用 Green 進行驗證 | 不適合有狀態的應用 |
金絲雀部署 (Canary Deployment)
先讓新版本服務少量流量（如 5%），觀察無誤後逐步增加：
| 階段 | 新版本流量 | 觀察時間 | 判斷標準 | |:----:|:----------:|:--------:|---------| | Phase 1 | 5% | 30 分鐘 | 錯誤率未上升 | | Phase 2 | 25% | 2 小時 | 無用戶客訴 | | Phase 3 | 75% | 4 小時 | 所有指標正常 | | Phase 4 | 100% | — | 部署完成 |
滾動更新 (Rolling Update)
逐台替換舊版實例，Kubernetes 預設採用此策略：
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # 最多可以多啟動 25% 的新 Pod
maxUnavailable: 25% # 最多可以關閉 25% 的舊 Pod
CI/CD Pipeline 實戰配置
name: CI/CD Pipeline
on:
push:
branches: [main, staging]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npm ci
- run: npm run lint
- run: npm run test
- run: npm run build
deploy-staging:
if: github.ref == 'refs/heads/staging'
needs: test
runs-on: ubuntu-latest
steps:
- run: echo "Deploy to staging..."
deploy-production:
if: github.ref == 'refs/heads/main'
needs: test
runs-on: ubuntu-latest
steps:
- run: echo "Deploy to production..."
CI/CD 常見問題與解決方案
| 問題 | 原因 | 解決方案 | |------|------|---------| | Build 不穩定、有時過有時不過 | 非確定性測試（依賴順序或時間） | 隔離測試、固定 seed | | 部署時間過長 | 映像檔過大、基礎設施冷啟動 | 多階段建置、快取層 | | 資料庫遷移導致服務中斷 | migration 與程式碼更新順序錯誤 | 向前相容的 migration | | 開發者繞過 CI 直接部署 | 流程太繁瑣或太耗時 | 簡化流程、減少建置時間 |
CI/CD：讓軟體交付自動化
CI/CD（Continuous Integration / Continuous Deployment）是現代軟體開發的標準實踐。它讓每次程式碼變更都自動經過測試、建置、部署。
CI vs CD 的區別
| 概念 | CI（持續整合） | CD（持續部署） | |:----|:------------|:------------| | 時機 | 每次 Push 或 PR | CI 通過後 | | 做的事 | 跑測試、語法檢查、建置 | 部署到 Staging / Production | | 成功條件 | 所有測試通過 | 部署成功、Health Check 通過 | | 失敗處理 | 阻擋 PR 合併 | 自動 Rollback |
為什麼需要 CI/CD？
- 省時間：不用手動跑測試、手動上傳檔案
- 降低風險：每次變更都經過相同的流程，減少人為錯誤
- 快速迭代：一天可以部署多次，而不是一週一次
- 團隊協作：確保每個人的變更不會破壞 main 分支
下一章預告：GitHub Actions
GitHub Actions 是目前最受歡迎的 CI/CD 平台之一。下一章教你建立第一個 Workflow——Push 時自動跑測試。