CI/CD 是什麼？持續整合與持續部署入門教學【2025】

軟體開發最怕什麼？上線前才發現程式碼有問題，整個團隊熬夜緊急修復，卻在修好 A bug 後又跑出 B bug。這種惡夢場景，其實可以透過 CI/CD 來避免。

CI/CD 是 DevOps 的核心實踐，也是現代軟體開發團隊的標準配備。它讓程式碼的整合與部署變成自動化流程，而不是依賴人工手動操作。這篇文章將帶你從概念到實作，完整理解 CI/CD 的原理與建置方法。

---

CI/CD 是什麼？

CI/CD 是兩個概念的組合：CI（Continuous Integration，持續整合） 與 CD（Continuous Delivery/Deployment，持續交付/部署）。

CI 持續整合是什麼？

持續整合指的是開發者頻繁地將程式碼合併到主分支，每次合併都會觸發自動化建置與測試。

傳統開發模式中，每個開發者在自己的分支上工作數週甚至數月，最後才嘗試合併。這時候往往發現程式碼互相衝突，整合過程痛苦又耗時——這就是所謂的「整合地獄」。

CI 的核心理念是「小步快跑」：

• 開發者每天多次提交程式碼
• 每次提交自動觸發建置與測試
• 發現問題立即修復，不讓問題累積

CD 持續交付 vs 持續部署

CD 有兩種解釋，容易混淆：

持續交付（Continuous Delivery）：程式碼通過所有測試後，隨時處於可部署狀態。但實際部署到生產環境仍需人工核准。

持續部署（Continuous Deployment）：比持續交付更進一步，通過測試的程式碼自動部署到生產環境，完全不需人工介入。

項目	持續交付	持續部署
自動化程度	到 Staging	到 Production
部署核准	需要人工	完全自動
適用情境	需要審核的環境	高度成熟的團隊
部署頻率	數天到數週	數小時到數天

大多數團隊會先實作持續交付，在建立足夠信心後才進階到持續部署。

想深入了解 CI/CD 在整個 DevOps 流程中的定位，可以參考我們的 DevOps 完整指南。

---

為什麼需要 CI/CD？

問題一：整合地獄

沒有 CI 的團隊，整合日通常是災難日。開發者各自開發數週後，突然要把所有程式碼合併在一起。衝突、相依性問題、功能互相影響⋯⋯解決這些問題往往比開發本身更耗時。

CI 的解法：每天多次整合，問題即時發現、即時修復。

問題二：手動部署的風險

「部署 SOP 有 47 個步驟，我漏了第 23 步。」

手動部署最大的問題是不可靠。即使有 SOP，人為錯誤還是會發生。更糟的是，每次部署的步驟可能因人而異，導致環境不一致。

CD 的解法：把部署步驟寫成程式碼，每次執行都一模一樣。

問題三：上線恐懼症

當部署變得複雜且風險高，團隊會傾向減少部署次數。一個月部署一次聽起來更「安全」，但實際上是讓每次部署的變更量變得更大、風險更高。

CI/CD 的解法：讓部署變得簡單、頻繁、低風險。小變更比大變更容易除錯。

DORA 研究數據

根據 DORA（DevOps Research and Assessment）的研究，實作 CI/CD 的高效能團隊：

• 部署頻率比低效能團隊高 208 倍
• 變更前置時間快 106 倍
• 服務恢復時間快 2,604 倍
• 變更失敗率低 7 倍

這些數據說明 CI/CD 不只是技術選擇，而是競爭力的關鍵。

---

CI/CD Pipeline 設計

Pipeline 是 CI/CD 的核心概念。它定義了程式碼從提交到部署的完整流程，每個階段稱為一個 Stage。

典型 Pipeline 結構

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│  Build  │ -> │  Test   │ -> │   QA    │ -> │ Staging │ -> │  Prod   │
│  建置   │    │  測試   │    │  品保   │    │  預備   │    │  正式   │
└─────────┘    └─────────┘    └─────────┘    └─────────┘    └─────────┘

Stage 1: Build（建置）

這個階段的目標是確保程式碼可以成功編譯。

# 以 Node.js 專案為例
build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

Stage 2: Test（測試）

自動執行各種測試來驗證程式碼品質。

測試類型：

• 單元測試：測試最小功能單位，執行速度快
• 整合測試：測試多個模組的互動
• 端對端測試：模擬真實使用者操作

test:
  stage: test
  script:
    - npm run test:unit
    - npm run test:integration
  coverage: '/Coverage: \d+.\d+%/'

Stage 3: Security Scan（安全掃描）

現代 Pipeline 通常會加入安全掃描。

security:
  stage: test
  script:
    - npm audit
    - trivy image myapp:${CI_COMMIT_SHA}

Stage 4: Deploy（部署）

將建置好的應用程式部署到目標環境。

deploy_staging:
  stage: deploy
  script:
    - kubectl apply -f k8s/staging/
  environment:
    name: staging
    url: https://staging.example.com

插圖：CI/CD Pipeline 流程圖

場景描述： 一張流程圖展示典型的 CI/CD Pipeline 階段，從 Source Code 開始，經過 Build、Test、Security Scan、Deploy to Staging、Deploy to Production，每個階段用不同顏色的方塊表示，箭頭顯示流程方向，並標示每個階段的主要任務。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: cicd-pipeline-stages-flow

---

CI 持續整合實作

實作 CI 的關鍵在於建立快速且可靠的回饋機制。開發者提交程式碼後，應該在幾分鐘內就知道結果。

CI 實作要點

1. 保持建置快速

CI 建置理想時間是 10 分鐘以內。如果建置太慢：

• 開發者會忽略 CI 結果
• 問題發現太晚，修復成本增加

加速技巧：

• 使用平行測試
• 善用快取（node_modules、Maven repo）
• 只執行受影響的測試

2. 維護穩定的測試

最糟糕的情況是測試不穩定（Flaky Test）——同樣的程式碼有時候過、有時候不過。這會讓團隊失去對 CI 的信任。

# 處理不穩定測試的策略
test:
  retry:
    max: 2
    when: script_failure

3. 建立主分支保護

確保只有通過 CI 的程式碼才能合併到主分支。

# GitHub Branch Protection Rules
- Require status checks to pass
- Require branches to be up to date
- Include administrators

CI 實作範例：GitHub Actions

name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm run test -- --coverage

      - name: Build
        run: npm run build

      - name: Upload coverage
        uses: codecov/codecov-action@v3

自動化測試策略

測試金字塔原則：

        /\
       /  \   E2E 測試（少量）
      /----\
     /      \  整合測試（適量）
    /--------\
   /          \ 單元測試（大量）
  /__________\

• 70% 單元測試：快速、穩定、覆蓋所有邏輯
• 20% 整合測試：驗證模組間互動
• 10% E2E 測試：驗證關鍵使用者流程

想建立自動化測試流程但不知從何開始？預約架構諮詢，讓我們幫你設計適合的測試策略。

---

CD 持續部署實作

CD 的挑戰在於如何在不影響使用者的情況下，安全地將新版本部署到生產環境。

部署策略比較

Rolling Update（滾動更新）

逐步替換舊版本的 Pod，不需要額外資源。

# Kubernetes Rolling Update
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

優點：資源效率高、零停機 缺點：回滾較慢、新舊版本暫時並存

Blue-Green Deployment（藍綠部署）

同時維護兩個完全相同的環境，流量瞬間切換。

         ┌─────────────┐
         │   Router    │
         └──────┬──────┘
                │
    ┌───────────┼───────────┐
    │           │           │
    ▼           │           ▼
┌───────┐       │       ┌───────┐
│ Blue  │       │       │ Green │
│ (v1)  │◄──────┘       │ (v2)  │
└───────┘               └───────┘
   舊版                    新版

優點：可瞬間回滾、測試完整環境 缺點：需要雙倍資源

Canary Deployment（金絲雀部署）

先將少量流量導向新版本，觀察無誤後再逐步增加。

# Istio Canary 設定
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
    - route:
      - destination:
          host: myapp
          subset: v1
        weight: 90
      - destination:
          host: myapp
          subset: v2
        weight: 10

優點：風險最低、可即時監控 缺點：設定複雜、需要流量管理

插圖：部署策略比較圖

場景描述： 一張並排比較圖展示三種部署策略：Rolling Update（顯示漸進替換的 Pod）、Blue-Green（顯示兩個環境與流量切換）、Canary（顯示流量百分比分配），每種策略用不同顏色區分，並標示優缺點。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: deployment-strategies-comparison

CD 實作範例：GitLab CI/CD

stages:
  - build
  - test
  - deploy_staging
  - deploy_production

deploy_staging:
  stage: deploy_staging
  script:
    - kubectl apply -f k8s/staging/
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

deploy_production:
  stage: deploy_production
  script:
    - kubectl apply -f k8s/production/
  environment:
    name: production
    url: https://www.example.com
  when: manual  # 手動觸發
  only:
    - main

回滾策略

無論部署策略多完善，都需要準備回滾計畫。

# Kubernetes 回滾
kubectl rollout undo deployment/myapp

# 查看部署歷史
kubectl rollout history deployment/myapp

# 回滾到特定版本
kubectl rollout undo deployment/myapp --to-revision=2

---

CI/CD 工具比較

市面上有眾多 CI/CD 工具，選擇時應考量團隊現有技術棧與需求。

主流工具比較表

工具	類型	特色	適合團隊
GitHub Actions	SaaS	與 GitHub 深度整合	GitHub 使用者
GitLab CI/CD	SaaS/Self-hosted	完整 DevOps 平台	需要整合方案
Jenkins	Self-hosted	彈性高、插件多	需要高度客製化
Azure Pipelines	SaaS	Azure 生態整合	微軟技術棧
CircleCI	SaaS	速度快、設定簡單	快速迭代團隊

GitHub Actions

優點：

• 與 GitHub 無縫整合
• Marketplace 有大量現成 Action
• YAML 設定直觀

限制：

• 公有 repo 免費，私有 repo 有分鐘限制
• 複雜流程設定較繁瑣

GitLab CI/CD

優點：

• 內建 CI/CD，無需額外設定
• 完整的 DevOps 平台
• 可自建 Runner

限制：

• 學習曲線較陡
• 自建需要維護成本

詳細的工具比較與選擇建議，可以參考 DevOps 工具完整指南。如果你的團隊使用微軟技術棧，也可以參考 Azure DevOps 完整教學。

插圖：CI/CD 工具生態圖

場景描述： 一張工具生態系統圖，中心是「CI/CD」，周圍放射狀排列各種工具分類：版本控制（GitHub, GitLab, Bitbucket）、CI/CD 平台（Jenkins, CircleCI, Azure Pipelines）、容器化（Docker, Kubernetes）、監控（Prometheus, Grafana），每個工具用其官方圖示表示。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: cicd-tools-ecosystem-map

---

CI/CD 實作範例

以下是一個完整的 Node.js 專案 CI/CD 範例。

專案結構

myapp/
├── src/
├── tests/
├── Dockerfile
├── k8s/
│   ├── deployment.yaml
│   └── service.yaml
└── .github/
    └── workflows/
        └── cicd.yaml

完整 Pipeline 範例

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # Stage 1: 建置與測試
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run unit tests
        run: npm run test:unit -- --coverage

      - name: Run integration tests
        run: npm run test:integration

      - name: Build application
        run: npm run build

      - name: Upload build artifacts
        uses: actions/upload-artifact@v3
        with:
          name: build
          path: dist/

  # Stage 2: 建置 Docker Image
  build-image:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}

    steps:
      - uses: actions/checkout@v4

      - name: Download build artifacts
        uses: actions/download-artifact@v3
        with:
          name: build
          path: dist/

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

  # Stage 3: 部署到 Staging
  deploy-staging:
    needs: build-image
    runs-on: ubuntu-latest
    environment:
      name: staging
      url: https://staging.example.com

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to Staging
        run: |
          kubectl set image deployment/myapp \
            myapp=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=staging

  # Stage 4: 部署到 Production（手動觸發）
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://www.example.com

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to Production
        run: |
          kubectl set image deployment/myapp \
            myapp=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=production

---

CI/CD 最佳實踐

1. 程式碼即設定（Pipeline as Code）

將 Pipeline 定義存放在版本控制中，享受程式碼管理的所有好處：版本紀錄、Code Review、分支管理。

2. 環境一致性

使用 Docker 確保建置環境一致。

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist/ ./dist/
CMD ["node", "dist/index.js"]

3. 密鑰管理

千萬不要把密鑰寫在程式碼或 Pipeline 設定裡。

# 正確做法：使用 Secrets
env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

4. 建立有意義的 Artifact

保留建置產出物，方便除錯與稽核。

- name: Upload test results
  uses: actions/upload-artifact@v3
  if: always()
  with:
    name: test-results
    path: test-results/
    retention-days: 30

5. 監控 Pipeline 效能

追蹤 Pipeline 執行時間，定期優化。

指標	建議值	說明
總建置時間	< 10 分鐘	超過會降低開發效率
測試覆蓋率	> 80%	低於難以保證品質
Pipeline 成功率	> 95%	低於表示有不穩定問題

CI/CD 也是 DevOps 學習路線圖中的核心技能之一。建立完 CI/CD 後，下一步通常是建立監控系統，可以參考 DevOps 監控指南。

---

常見問題 FAQ

CI/CD 跟 DevOps 有什麼關係？

CI/CD 是 DevOps 實踐的核心組成部分。DevOps 是一種文化與方法論，而 CI/CD 是實現 DevOps 自動化交付目標的具體技術實踐。

CI/CD 需要多少時間建置？

基礎 Pipeline 可以在幾天內建立完成。但要建立成熟的 CI/CD 流程，包含完整測試、安全掃描、多環境部署，通常需要持續迭代數月。

小團隊需要 CI/CD 嗎？

需要。事實上小團隊更需要自動化來提高效率。GitHub Actions、GitLab CI/CD 等工具的免費方案對小團隊來說已經足夠。

持續部署安全嗎？

持續部署的前提是有足夠的自動化測試與監控。如果測試覆蓋完整、監控到位，持續部署反而比手動部署更安全，因為它消除了人為錯誤。

CI/CD 跟 GitOps 有什麼不同？

CI/CD 是自動化建置與部署的流程。GitOps 是一種實踐方式，將 Git 作為唯一真實來源（Single Source of Truth），所有變更都透過 Git 提交觸發。GitOps 可以視為 CD 的進階實踐。

插圖：CI/CD 與 DevOps 關係圖

場景描述： 一張概念圖展示 CI/CD 在 DevOps 中的定位，DevOps 作為外層大圓（包含文化、協作、自動化），CI/CD 作為內層圓（包含建置、測試、部署），並標示相關概念如 IaC、Monitoring、Security 如何與 CI/CD 整合。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: cicd-devops-relationship-diagram

---

結論

CI/CD 是現代軟體開發的基礎設施。它不只是技術工具的選擇，更是團隊開發文化的體現。

實作 CI/CD 的價值：

1. 快速回饋：問題早發現、早解決
2. 降低風險：小步快跑比大爆發更安全
3. 提升效率：自動化減少重複工作
4. 建立信心：可靠的流程讓團隊專注創造價值

開始建置 CI/CD 不需要一步到位。可以先從最基本的自動化測試開始，逐步加入建置、部署、監控。重要的是持續改進，讓 Pipeline 越來越完善。

想在團隊中建立高效的 CI/CD 流程？預約架構諮詢，我們幫你設計最適合的 Pipeline 架構，從建置到部署一次到位。