本章是全書最實戰的部分，透過一個完整的範例情境，從無到有建構出一條 CI/CD Pipeline，並逐步微調與重構。

Pipeline 的三個核心 Stage#

Build：建構#

• 編譯程式碼、打包產物
• Artifacts 是關鍵概念：Job 產出的檔案（如編譯後的 binary、測試報告）可透過 Artifacts 傳遞給下游 Stage

build:
  stage: build
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

設定 expire_in 控制 Artifacts 的保留時間，避免佔用過多儲存空間。
短期的建構產物建議設為 1 小時或 1 天。

Deploy：部署#

• 將 Build Stage 產出的 Artifacts 部署到目標環境
• 支援多種部署方式：SCP 檔案傳輸、Docker 部署、Kubernetes 部署
• 一個 Stage 中可以包含多個 Job 並行執行，例如同時部署到多個環境

Test：自動化測試#

• 在部署後執行驗收測試，確認部署成功
• 可整合單元測試、整合測試、E2E 測試

Pipeline 的 Stage 順序（build ➡️ deploy ➡️ test 或 build ➡️ test ➡️ deploy）取決於你的策略。
書中先 deploy 再 test 的做法適合部署到 staging 環境後跑驗收測試的場景。

Pipeline 微調與重構#

多條 Pipeline#

當專案複雜度增加，你可能需要：

• Merge Request Pipeline：只在 MR 時觸發，跑快速的 lint + unit test
• Branch Pipeline：推送到特定分支時觸發完整的 build + deploy
• Scheduled Pipeline：排程執行的完整測試或安全掃描

條件觸發#

使用 rules 精確控制 Job 何時執行：

deploy-production:
  stage: deploy
  script:
    - deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
    - when: never

rules 取代了舊版的 only/except，提供更靈活的條件判斷。新專案建議直接使用 rules。

Protected Variables#

敏感資訊（如部署金鑰、API Token）應使用 CI/CD Variables 存放，並標記為 Protected：

• Protected Variable 只會在 Protected Branch 或 Protected Tag 的 Pipeline 中被注入
• 確保 feature branch 的 Pipeline 無法存取正式環境的機密

永遠不要將密鑰寫在 .gitlab-ci.yml 中。
即使你之後刪除了該行，Git 歷史紀錄仍然保留。
使用 CI/CD Variables 搭配 Protected + Masked 設定。

開發者的行動指南#

1. 從最小可行的 Pipeline 開始：一個 Stage、一個 Job，確認能跑再逐步擴充
2. 善用 Artifacts 傳遞建構產物：避免在每個 Stage 重複建構
3. MR Pipeline 要快：開發者的 feedback loop 越短越好，MR Pipeline 應在 5 分鐘內完成
4. 正式環境部署設為 manual：避免意外部署，由人工確認後再觸發
5. 機密管理是第一優先：設定好 Protected Variables 後再寫部署腳本