🚀 GitLab CI/CD 進階：Artifacts、Stages、Environment、Blue-Green、Canary 實戰完整指南

🚀 GitLab CI/CD 進階：Artifacts、Stages、Environment、Blue-Green、Canary 實戰完整指南

延續先前的 GitLab CI/CD 入門與 Docker 自動部署篇，本篇將正式進入企業級的 CI/CD 架構，深入解析：

• 📦 Artifacts：構建產物管理（Build → Test → Deploy）
• 📚 Stages：多階段 Pipeline 設計
• 🌐 Environment：環境控制（Dev / Test / Staging / Prod）
• 🔁 Blue-Green Deployment：零停機部署
• 🟡 Canary Deployment：百分比流量部署
• 🧪 Review Apps：MR 自動建立暫時環境

此篇屬於「企業級 GitLab CI/CD 進階教學」，可直接應用於中大型開發團隊、SaaS、微服務環境。

---

📌 第一章：CI/CD 進階架構總覽

以下是企業常用的完整 CI/CD 流程：

Commit → Lint → Build → Test → Security Scan → Package → Deploy Staging → Deploy Prod

這三個要素是核心：

• 📦 Artifacts — 各階段共用建置產物
• 🧱 Stages — 有順序的執行階段
• 🌐 Environment — 部署環境管理

---

📦 第二章：Artifacts — 流程間傳遞 Build 結果

CI/CD 在 Build → Test → Deploy 之間傳遞檔案，必須使用 artifacts。

2.1 基本範例

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

2.2 常見用途

• 前端 dist/
• 後端 compile 結果
• terraform plan
• dockerfile build logs

Artifacts 是跨 stage 溝通的最佳方式。

---

📚 第三章：Stages — 多階段 Pipeline 設計

Stages 定義整個 Pipeline 執行順序。

3.1 常見 Multi-Stage 設計

stages:
  - lint
  - build
  - test
  - package
  - staging
  - production

3.2 每個 stage 必須成功才能進下一階段

若 test 失敗 → package/staging/production 都不會執行。

---

🌐 第四章：Environment — 多環境部署（Dev/Test/Prod）

GitLab 可以建立 Environment 供部署使用：

4.1 基本例子

deploy_staging:
  stage: staging
  environment:
    name: staging
    url: https://staging.example.com
  script:
    - bash deploy.sh staging

4.2 多環境 Variables（強烈推薦）

於 GitLab 設置：

- STAGING_DB - STAGING_API_KEY - PRODUCTION_DB 搭配：

environment:
  name: production

GitLab 會自動使用該 Environment 的變數，避免手動調整錯誤。

---

🔁 第五章：Blue-Green Deployment — 零停機部署

Blue-Green 概念：建立兩個 Production 環境（Blue 與 Green）。 更新時只更新另一個環境 → 測試成功後切流量。

5.1 典型架構（Nginx / Load Balancer）

Blue  ← 正在提供服務
Green ← 新版本準備好，等待切換

5.2 GitLab CI 實作

deploy_blue:
  stage: production
  environment:
    name: blue
  script:
    - docker compose -f docker-compose.blue.yml up -d

deploy_green:
  stage: production
  environment:
    name: green
  script:
    - docker compose -f docker-compose.green.yml up -d

5.3 切換流量

switch_traffic:
  stage: production
  script:
    - ln -sf /etc/nginx/sites-enabled/green.conf /etc/nginx/sites-enabled/active.conf
    - nginx -s reload

這是在多數企業最常用的藍綠部署模式。

---

🟡 第六章：Canary Deployment — 逐步流量釋出

Canary Deployment 目的：先將少部分流量給新版本。

6.1 流量分配範例（Nginx）

split_clients "${remote_addr}" $upstream {
  10%     "canary";
  *       "stable";
}

6.2 GitLab CI Canary 設定

deploy_canary:
  stage: production
  environment:
    name: production
    deployment_tier: canary
  script:
    - bash deploy.sh canary

6.3 Canary → Promote 流程

promote_to_stable:
  stage: production
  script:
    - bash promote.sh

Canary 適合 API、SaaS 服務的漸進式更新。

---

🧪 第七章：Review Apps（MR 自動生成測試環境）

Review Apps 每次 Merge Request 都自動建立獨立測試環境。

7.1 設定方式

review_app:
  stage: staging
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://review-$CI_COMMIT_REF_SLUG.example.com
  script:
    - bash deploy_review.sh
  only:
    - merge_requests

7.2 當 MR 關閉時自動刪除

environment:
  on_stop: stop_review

這是大型團隊最常用的流程。

---

📌 第八章：完整進階版 .gitlab-ci.yml（可直接用）

stages:
  - lint
  - build
  - test
  - package
  - staging
  - canary
  - production

lint:
  stage: lint
  script:
    - npm run lint

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

test:
  stage: test
  script:
    - npm test

package:
  stage: package
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

deploy_staging:
  stage: staging
  environment:
    name: staging
  script:
    - bash deploy.sh staging

deploy_canary:
  stage: canary
  environment:
    name: production
    deployment_tier: canary
  script:
    - bash deploy.sh canary
  only:
    - main

deploy_production:
  stage: production
  environment:
    name: production
  script:
    - bash deploy.sh stable
  only:
    - main

---

📌 第九章：最佳實務（企業使用建議）

• 🚫 Production 強制 MR 才能合併（禁止直接推 main）
• 🔐 使用 Protected Variables 管理金鑰與環境設定
• 📦 Artifact retention 需依專案調整（避免佔空間）
• 🧪 Canary + Monitoring（必備監控）
• 🔄 Blue-Green 用於大版本更新，Canary 用於 API 小更新

---

📌 結語

本篇完整解析 GitLab CI/CD 的進階部署概念：Artifacts、Stages、Environment、Blue-Green、Canary、Review Apps。 這些功能組合起來後，將能支撐大型系統、微服務架構以及多環境佈署管線，是企業部署不可或缺的 DevOps 能力。

下一篇將推出： 《GitLab Runner 高效管理：Docker Executor、Cache、Scaling Runner、Auto DevOps 深入解析》

---