什麼是 CI/CD？
CI（持續整合）：每次程式碼推送都自動觸發建置與測試
CD（持續交付/部署）：通過測試後自動部署到目標環境
目標：縮短從「完成開發」到「上線服務」的時間，同時保障品質
- 傳統方式：每週/每月手動部署，風險集中
- CI/CD 方式：每天多次小步部署，問題早發現早修復
GitLab CI Pipeline 結構
① push 程式碼 → 觸發 Pipeline
② build stage → 編譯、打包 Docker 映像
③ test stage → 單元測試、E2E 測試、Lint
④ deploy stage → 自動部署到目標環境
同一 stage 的 jobs 並行執行；下一個 stage 需等上一個 stage 全部完成
Dockerfile 最佳實務
- 使用多階段建置，最終映像只含執行所需檔案
- 先 COPY package.json，再 COPY 程式碼（利用 Layer 快取）
- 使用非 root 使用者執行應用（安全最佳實務）
- 選擇 alpine 基底映像（比 debian 小 5-10 倍）
- 加入
.dockerignore排除 node_modules、.git 等
GitLab CI 核心變數
| 變數 | 說明 |
|---|---|
$CI_COMMIT_SHA |
目前 commit 的完整 SHA |
$CI_REGISTRY_IMAGE |
Container Registry 的映像路徑 |
$CI_COMMIT_BRANCH |
目前 branch 名稱 |
$CI_PIPELINE_URL |
Pipeline 的 GitLab 連結 |
部署策略比較
| 策略 | 特點 |
|---|---|
| Rolling Update | 逐步替換容器，服務不中斷 |
| Blue-Green | 兩套環境切換，回滾最快 |
| Canary | 小比例流量先驗證，風險最低 |
CI/CD 安全最佳實務
- API 金鑰存在 GitLab CI 變數，設為 Protected + Masked
- 部署用 SSH 金鑰只給最小必要的權限
- 每次建置後掃描 Docker 映像漏洞（Trivy）
- 生產部署需要手動審核（
when: manual） - 定期輪換 Runner Token 和部署金鑰
- 使用 Protected Branches 限制誰能推送到 main
本教學對應的真實架構
本教學網站（FastTrack）的部署方式：
- 程式碼推送到 GitLab
mainbranch - GitLab CI 自動建置 Docker 映像，推送到 Registry
- 自架 Runner（標籤
deploy）拉取最新映像 docker compose up -d --no-build更新服務
這正是你學完本教學後可以直接套用的真實方案！
1 / 7