Software Deployment：軟體部署策略與最佳實踐【2025】

新版本要上線了，你敢直接全部切換嗎？

軟體部署不只是把程式碼放到伺服器上這麼簡單。選擇正確的部署策略，可以讓你在最小風險下完成版本更新；選錯了，可能導致服務中斷、使用者流失。

這篇文章將介紹五種主流的軟體部署策略，幫助你根據專案需求選擇最適合的方式。

為什麼部署策略很重要？

部署策略決定了「如何」將新版本推送給使用者，直接影響：

服務可用性

不同策略的停機時間差異很大：

風險控制

新版本可能有 Bug，不同策略的影響範圍：

資源成本

不同策略需要的基礎設施資源不同：

想了解更多部署基礎知識，請參考我們的 程式部署完整指南。

策略一：Recreate（重建部署）

最簡單粗暴的部署方式：停掉舊版本，啟動新版本。

運作方式

時間軸 →

舊版本 v1.0：████████████░░░░░░░░░░░░
                        ↓ 停止
新版本 v2.0：░░░░░░░░░░░░████████████
                        ↑ 啟動

停機時間：████（數分鐘）

步驟

1. 停止所有舊版本服務
2. 部署新版本程式碼
3. 啟動新版本服務
4. 驗證服務正常

優缺點

優點：
- 最簡單，不需要複雜設定
- 不會有新舊版本同時運行的問題
- 資源需求最低

缺點：
- 有停機時間
- 無法快速回滾（需要重新部署）
- 使用者會感受到服務中斷

適用情境

• 開發/測試環境
• 可接受短暫停機的內部系統
• 非關鍵業務應用
• 預算極度有限

Kubernetes 實作

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: Recreate  # 重建策略
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0

策略二：Rolling Update（滾動更新）

逐步替換舊版本，是 Kubernetes 的預設策略。

運作方式

時間軸 →

Pod 1：v1 v1 v1 v2 v2 v2 v2 v2 v2
Pod 2：v1 v1 v1 v1 v2 v2 v2 v2 v2
Pod 3：v1 v1 v1 v1 v1 v2 v2 v2 v2
Pod 4：v1 v1 v1 v1 v1 v1 v2 v2 v2

服務持續可用，逐步切換

步驟

1. 啟動一個新版本實例
2. 等待新實例健康檢查通過
3. 停止一個舊版本實例
4. 重複直到全部替換完成

優缺點

優點：
- 零停機時間
- 不需要額外資源（或只需少量）
- 自動化程度高
- 可控制更新速度

缺點：
- 部署期間新舊版本同時存在
- 可能有相容性問題（API 版本、資料庫 Schema）
- 回滾較慢（需要反向滾動）
- 需要處理 Session 問題

適用情境

• 大多數 Web 應用
• 無狀態服務
• API 向後相容的更新
• Kubernetes 環境

💡 不確定該選哪種部署策略？讓 VibeFix 幫你評估

Kubernetes 實作

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 最多多啟動 1 個
      maxUnavailable: 1  # 最多 1 個不可用
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0
        readinessProbe:  # 重要！確保新版本就緒
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

重要參數說明

保守設定（零停機）：

maxSurge: 1
maxUnavailable: 0

積極設定（快速部署）：

maxSurge: 50%
maxUnavailable: 50%

策略三：Blue-Green Deployment（藍綠部署）

維護兩套完全相同的環境，透過切換流量完成部署。

運作方式

                    Load Balancer
                         │
            ┌────────────┼────────────┐
            │                         │
            ▼                         ▼
    ┌──────────────┐         ┌──────────────┐
    │    Blue      │         │    Green     │
    │   (v1.0)     │         │   (v2.0)     │
    │   Active     │         │   Standby    │
    └──────────────┘         └──────────────┘

部署流程：
1. 目前 Blue 服務中
2. 在 Green 部署 v2.0
3. 測試 Green 環境
4. 切換 Load Balancer 到 Green
5. Blue 變成備援（可快速回滾）

步驟

1. 準備兩套環境：Blue（目前線上）和 Green（備援）
2. 在 Green 環境部署新版本
3. 在 Green 環境進行完整測試
4. 切換 Load Balancer/DNS 指向 Green
5. 監控 Green 環境
6. 確認無誤後，Blue 可更新為新版本或保留為備援

優缺點

優點：
- 零停機時間
- 快速回滾（秒級，只需切換流量）
- 可在正式環境完整測試新版本
- 新舊版本完全隔離

缺點：
- 需要雙倍資源
- 資料庫 Schema 變更需特別處理
- 設定較複雜
- 成本較高

適用情境

• 關鍵業務系統
• 需要快速回滾能力
• 有充足預算
• 金融、電商等對穩定性要求高的產業

實作方式

使用 Nginx 切換

# /etc/nginx/conf.d/upstream.conf

# 方式一：註解切換
upstream backend {
    server blue.internal:8080;  # 目前使用
    # server green.internal:8080;  # 待切換
}

# 方式二：使用變數
upstream backend {
    server $active_backend:8080;
}

使用 AWS ALB

# 切換 Target Group
aws elbv2 modify-listener \
    --listener-arn arn:aws:elasticloadbalancing:xxx \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:xxx:targetgroup/green

使用 Kubernetes Service

# 透過修改 selector 切換
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    version: green  # 切換時改為 blue 或 green
  ports:
  - port: 80
    targetPort: 8080

策略四：Canary Deployment（金絲雀部署）

先將新版本部署給小部分使用者，驗證無誤後再全面推送。

運作方式

流量分配變化：

階段 1：  Canary (v2.0) ██░░░░░░░░░░░░░░░░░░  5%
          Stable (v1.0) ██████████████████  95%

階段 2：  Canary (v2.0) █████░░░░░░░░░░░░░░░  25%
          Stable (v1.0) ███████████████     75%

階段 3：  Canary (v2.0) ██████████░░░░░░░░░░  50%
          Stable (v1.0) ██████████          50%

階段 4：  Canary (v2.0) ████████████████████  100%
          Stable (v1.0)                       0%

名稱由來

「金絲雀」來自礦工帶金絲雀進礦坑的做法：金絲雀對有毒氣體敏感，如果金絲雀死了，礦工就知道要撤離。

在軟體部署中，Canary 版本就是那隻「金絲雀」——先讓小部分流量測試新版本，如果出問題，影響範圍有限。

步驟

1. 部署新版本到 Canary 環境
2. 將少量流量（如 5%）導向 Canary
3. 監控關鍵指標（錯誤率、延遲、轉換率）
4. 如果指標正常，逐步增加流量比例
5. 如果指標異常，立即回滾（將流量切回 Stable）
6. 直到 100% 流量都導向新版本

優缺點

優點：
- 風險最低（初期只影響少數使用者）
- 可以在真實流量下驗證
- 問題可被快速發現和修復
- 支援漸進式推送

缺點：
- 設定最複雜
- 需要成熟的監控系統
- 部署時間較長
- 需要流量控制能力

適用情境

• 大流量系統
• 新功能風險較高
• 有完善監控系統
• 需要 A/B 測試

💡 想建立完善的部署流程？讓 VibeFix 專家幫你規劃

Kubernetes + Istio 實作

# VirtualService 控制流量分配
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: stable
      weight: 95
    - destination:
        host: myapp
        subset: canary
      weight: 5

---
# DestinationRule 定義版本
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
  - name: stable
    labels:
      version: v1.0
  - name: canary
    labels:
      version: v2.0

使用 Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: {duration: 10m}  # 觀察 10 分鐘
      - setWeight: 25
      - pause: {duration: 10m}
      - setWeight: 50
      - pause: {duration: 10m}
      - setWeight: 100
      analysis:
        templates:
        - templateName: success-rate
        startingStep: 1
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0

策略五：A/B Testing（A/B 測試）

根據使用者特徵將流量導向不同版本，用於功能實驗。

與 Canary 的差異

運作方式

使用者請求 → 判斷使用者特徵 → 路由到對應版本

特徵範例：
- User ID % 100 < 50 → Version A
- User ID % 100 >= 50 → Version B
- 地區 = TW → Version A
- 地區 = US → Version B
- 新用戶 → Version B（新功能）
- 舊用戶 → Version A（原功能）

適用情境

• 功能實驗
• UI/UX 優化
• 定價策略測試
• 新功能驗證

部署策略比較總表

部署前/中/後檢查清單

無論使用哪種策略，都應該遵循這些檢查項目。

部署前檢查

□ 程式碼已通過所有測試
□ 程式碼已經過 Code Review
□ 資料庫 Migration 已準備（如需要）
□ 設定檔已更新（環境變數、Feature Flags）
□ 依賴服務確認可用
□ 回滾計畫已準備
□ 團隊成員已通知
□ 監控儀表板已開啟
□ 備份已完成（如需要）

部署中監控

□ 部署進度正常
□ 健康檢查通過
□ 錯誤率在正常範圍
□ 回應時間在正常範圍
□ 資源使用率正常
□ 日誌無異常錯誤
□ 關鍵業務指標正常

部署後驗證

□ 所有端點可存取
□ 關鍵功能測試通過
□ 效能符合預期
□ 無異常錯誤日誌
□ 監控告警無觸發
□ 使用者反饋正常
□ 部署記錄已更新
□ 團隊已通知部署完成

如何選擇部署策略？

根據你的專案特性選擇：

決策流程

開始
  │
  ├─ 可以接受停機？
  │     │
  │     ├─ 是 → Recreate（最簡單）
  │     │
  │     └─ 否 → 繼續
  │
  ├─ 需要快速回滾？
  │     │
  │     ├─ 是，且預算充足 → Blue-Green
  │     │
  │     └─ 預算有限 → Rolling
  │
  ├─ 需要漸進式驗證？
  │     │
  │     └─ 是 → Canary
  │
  └─ 需要功能實驗？
        │
        └─ 是 → A/B Testing

按專案規模建議

按產業建議

VibeFix 部署策略顧問服務

選擇正確的部署策略需要考慮多個因素：

• 系統架構與技術堆疊
• 業務需求與 SLA 要求
• 團隊規模與技術能力
• 預算與資源限制
• 合規與安全要求

VibeFix 團隊提供完整的部署策略顧問服務。

服務範圍：
- 部署策略評估與建議
- CI/CD Pipeline 設計
- Kubernetes 部署設定
- 監控與告警整合
- 回滾機制設計

想了解更詳細的服務？查看 VibeFix 服務內容。

五種部署策略特性整理與選擇建議

沒有「最好」的部署策略，只有「最適合」的。選擇時考慮：

• Recreate：簡單、可接受停機
• Rolling：零停機、資源有限
• Blue-Green：需要快速回滾、預算充足
• Canary：需要漸進式驗證、有監控能力
• A/B Testing：需要功能實驗

透過這篇教學，你已經學會：

• 五種主流部署策略的原理與運作方式
• 各策略的優缺點與適用情境
• Kubernetes 實作方式
• 部署前/中/後的完整檢查清單
• 如何根據專案選擇策略

接下來，你可以學習 CI/CD 建置與部署流程，將部署策略整合進自動化流程。或者參考 Deployment Server 架設，建立集中化的部署管理系統。

部署失敗？別擔心

部署策略選擇與實作都需要經驗。VibeFix 團隊可以幫你評估最適合的策略，並協助實作。

幫我部署 →