Cloud Deploy 是什麼？Google Cloud 持續部署服務介紹

「CI/CD 聽起來很厲害，但設定 Jenkins 或 ArgoCD 好像很複雜...」

如果你用 GCP，其實有個更簡單的選擇：Cloud Deploy。它是 Google 專門為持續部署（CD）設計的託管服務，讓你不用自己架設和維護 CD 工具，就能實現自動化部署流程。

這篇文章會帶你認識 Cloud Deploy 的核心概念，了解它與其他 CI/CD 工具的差異，並實際動手設定一個多環境部署流程。

Cloud Deploy 基本介紹

在深入技術細節前，先搞清楚 Cloud Deploy 是什麼、能幫你解決什麼問題。

Cloud Deploy 是什麼？

Cloud Deploy 是 Google Cloud 的全託管持續部署服務，專門用來將應用程式部署到 GKE（Google Kubernetes Engine）、Cloud Run 或 GKE Enterprise。

簡單說，它幫你解決這個問題：

「我的程式碼已經打包好了，怎麼自動、安全地部署到不同環境？」

Cloud Deploy 的核心價值：

• 多環境管理：輕鬆設定 dev → staging → production 的部署流程
• 審批機制：Production 部署前可以設定人工審批
• 回滾功能：一鍵回滾到前一個穩定版本
• 可視化追蹤：清楚看到每個 Release 部署到哪個環境

與其他 CI/CD 工具的差異

Cloud Deploy 只專注於「持續部署」，這與其他工具有明顯區別：

典型的流程是：

1. Cloud Build：程式碼提交 → 編譯 → 測試 → 打包成容器映像
2. Cloud Deploy：容器映像 → 部署到 dev → staging → production

這種分工的好處是職責清晰，各自專注做好一件事。

適用情境

Cloud Deploy 最適合這些情境：

適合使用 Cloud Deploy
- 團隊使用 GKE 或 Cloud Run
- 需要多環境部署流程（dev/staging/prod）
- 需要 Production 部署前的人工審批
- 想要追蹤每個版本部署到哪個環境
- 不想自己架設維護 ArgoCD 或 Spinnaker

可能不適合
- 不是用 GKE 或 Cloud Run（Cloud Deploy 目前只支援這些目標）
- 只有單一環境，不需要複雜的部署流程
- 已經有成熟的 CD 工具且運作良好

想了解更多 GCP 的部署選項，可以參考 GCP 部署完整指南。

Cloud Deploy 核心概念

要使用 Cloud Deploy，需要先理解四個核心概念。這些概念環環相扣，構成完整的部署流程。

Delivery Pipeline

Delivery Pipeline（交付管線） 是最上層的概念，定義了「這個應用程式要部署到哪些環境」。

一個 Pipeline 包含：
- Pipeline 的名稱和描述
- 要部署到的環境列表（Targets）
- 環境的順序（dev → staging → prod）

# clouddeploy.yaml
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-app-pipeline
description: My application deployment pipeline
serialPipeline:
  stages:
    - targetId: dev
    - targetId: staging
    - targetId: prod
      profiles: [prod]

Target

Target（目標） 代表一個部署環境，例如 dev、staging、production。

每個 Target 定義了：
- 環境名稱
- 部署到哪個 GKE 叢集或 Cloud Run 服務
- 該環境特有的設定

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: dev
description: Development environment
gke:
  cluster: projects/my-project/locations/asia-east1/clusters/dev-cluster
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: Production environment
gke:
  cluster: projects/my-project/locations/asia-east1/clusters/prod-cluster
requireApproval: true  # Production 需要審批

Release

Release（發布） 代表一個特定版本的應用程式，準備要部署到 Pipeline 中的各個環境。

當你建立一個 Release：
- 它會綁定一個特定的容器映像版本
- 可以追蹤這個版本部署到哪些環境
- 每個環境的部署狀態都清楚可見

# 建立一個新的 Release
gcloud deploy releases create release-001 \
  --project=my-project \
  --region=asia-east1 \
  --delivery-pipeline=my-app-pipeline \
  --images=my-app=gcr.io/my-project/my-app:v1.0.0

Rollout

Rollout（推出） 是 Release 在特定 Target 的部署執行。

當 Release 部署到某個環境時，就會產生一個 Rollout：
- 記錄部署的狀態（進行中、成功、失敗）
- 記錄部署的時間和執行者
- 如果失敗，可以查看錯誤原因

概念總結

💡 CI/CD Pipeline 設定太複雜？ 如果你對這些概念還是覺得抽象，或是在設定過程中遇到困難，讓 VibeFix 幫你規劃，我們有豐富的 GCP 部署經驗。

Cloud Deploy 設定教學

接下來我們實際動手，設定一個完整的 Cloud Deploy 部署流程。

前置準備

在開始前，確保你有：

1. GCP 專案：已啟用計費
2. GKE 叢集或 Cloud Run 服務：作為部署目標
3. 容器映像：已推送到 Container Registry 或 Artifact Registry
4. gcloud CLI：已安裝並登入

啟用必要的 API

gcloud services enable clouddeploy.googleapis.com
gcloud services enable cloudbuild.googleapis.com

設定 IAM 權限

Cloud Deploy 需要足夠的權限來部署到 GKE 或 Cloud Run：

# 取得 Cloud Deploy 服務帳號
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
DEPLOY_SA="[email protected]"

# 授予 GKE 部署權限
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$DEPLOY_SA" \
  --role="roles/container.developer"

# 授予 Cloud Run 部署權限（如果使用 Cloud Run）
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$DEPLOY_SA" \
  --role="roles/run.developer"

建立 Delivery Pipeline

建立一個 YAML 檔案定義 Pipeline 和 Targets：

clouddeploy.yaml

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-app-pipeline
description: My application deployment pipeline
serialPipeline:
  stages:
    - targetId: dev
    - targetId: staging
    - targetId: prod
      profiles: [prod]
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: dev
description: Development environment
gke:
  cluster: projects/my-project/locations/asia-east1/clusters/dev-cluster
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: staging
description: Staging environment
gke:
  cluster: projects/my-project/locations/asia-east1/clusters/staging-cluster
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: Production environment
gke:
  cluster: projects/my-project/locations/asia-east1/clusters/prod-cluster
requireApproval: true

套用設定

gcloud deploy apply --file=clouddeploy.yaml --region=asia-east1

設定 Target 環境

如果使用 Cloud Run 而不是 GKE，Target 設定稍有不同：

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: dev
description: Development Cloud Run service
run:
  location: projects/my-project/locations/asia-east1

使用不同設定檔（Profiles）

不同環境可能需要不同的資源配置，可以用 Skaffold profiles 來管理：

skaffold.yaml

apiVersion: skaffold/v4beta5
kind: Config
metadata:
  name: my-app
deploy:
  kubectl:
    manifests:
      - k8s/*.yaml
profiles:
  - name: prod
    patches:
      - op: replace
        path: /deploy/kubectl/manifests
        value:
          - k8s/base/*.yaml
          - k8s/prod/*.yaml

建立 Release 與部署

建立 Release

gcloud deploy releases create release-v1-0-0 \
  --project=my-project \
  --region=asia-east1 \
  --delivery-pipeline=my-app-pipeline \
  --images=my-app=gcr.io/my-project/my-app:v1.0.0 \
  --source=.

建立 Release 後，Cloud Deploy 會自動部署到第一個 Target（dev）。

推進到下一個環境

當 dev 測試通過，可以推進到 staging：

gcloud deploy releases promote \
  --release=release-v1-0-0 \
  --delivery-pipeline=my-app-pipeline \
  --region=asia-east1

或者在 GCP Console 的 Cloud Deploy 頁面，點擊「Promote」按鈕。

Cloud Deploy 最佳實踐

設定好基本流程後，這些最佳實踐能讓你的部署更安全可靠。

多環境部署策略

循序漸進

建議至少設定三個環境：

環境隔離

每個環境應該有獨立的：
- GKE 叢集或 Cloud Run 服務
- 資料庫（使用不同的資料）
- 環境變數和 secrets

審批流程設定

Production 部署前應該有人工審批：

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: prod
description: Production environment
gke:
  cluster: projects/my-project/locations/asia-east1/clusters/prod-cluster
requireApproval: true

設定審批者

# 授予審批權限
gcloud projects add-iam-policy-binding my-project \
  --member="user:[email protected]" \
  --role="roles/clouddeploy.approver"

當 Release 要推進到 prod 時，審批者會收到通知，需要在 Console 或 CLI 核准：

gcloud deploy rollouts approve rollout-name \
  --release=release-v1-0-0 \
  --delivery-pipeline=my-app-pipeline \
  --region=asia-east1

回滾機制

如果部署出問題，Cloud Deploy 支援快速回滾：

回滾到前一個版本

gcloud deploy targets rollback prod \
  --delivery-pipeline=my-app-pipeline \
  --region=asia-east1

這會自動找到上一個成功的 Release，重新部署到該環境。

手動指定回滾版本

gcloud deploy releases promote \
  --release=release-v0-9-0 \  # 指定要回滾到的版本
  --delivery-pipeline=my-app-pipeline \
  --region=asia-east1 \
  --to-target=prod

回滾最佳實踐

1. 保留多個版本：確保舊版本的容器映像還在 Registry
2. 測試回滾流程：定期演練回滾，確保真的能用
3. 記錄回滾原因：每次回滾都應該記錄原因，事後分析

想深入了解 CI/CD 流程設計，可以參考 Build and Deploy 實戰。

FAQ 常見問題

Cloud Deploy 要收費嗎？

Cloud Deploy 本身按 Release 計費，每個 Release 約 $0.025。但主要費用會來自 GKE 或 Cloud Run 的運算資源。對於小型專案，Cloud Deploy 費用幾乎可以忽略。

Cloud Deploy 支援非 Kubernetes 的部署嗎？

目前 Cloud Deploy 主要支援：
- GKE（Google Kubernetes Engine）
- Cloud Run
- GKE Enterprise（Anthos）

如果你的應用不是容器化的，可能需要考慮其他方案，例如用 Cloud Build 直接部署到 Compute Engine 或 App Service。

可以跳過環境直接部署到 Production 嗎？

技術上可以，但不建議。Cloud Deploy 設計上鼓勵循序漸進的部署流程。如果你真的需要緊急部署，可以快速推進 Release 通過各個環境，或設定特殊的「hotfix」Pipeline。

Cloud Deploy 和 ArgoCD 有什麼差別？

如果你全用 GCP 且想要簡單，選 Cloud Deploy；如果你需要跨雲或更多彈性，選 ArgoCD。

如何整合 Cloud Build 和 Cloud Deploy？

在 Cloud Build 的 cloudbuild.yaml 中，建置完成後觸發 Cloud Deploy：

steps:
  # 建置容器
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA', '.']

  # 推送容器
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']

  # 建立 Cloud Deploy Release
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - 'deploy'
      - 'releases'
      - 'create'
      - 'release-$COMMIT_SHA'
      - '--delivery-pipeline=my-app-pipeline'
      - '--region=asia-east1'
      - '--images=my-app=gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA'

結語

Cloud Deploy 是 GCP 生態系中填補「持續部署」這塊拼圖的重要服務，特別適合：

• 使用 GKE 或 Cloud Run 的團隊：原生整合，設定簡單
• 需要多環境部署流程：內建 dev → staging → prod 支援
• 需要審批機制：Production 部署前的人工把關
• 不想自己維護 CD 工具：全託管服務，省心省力

重點整理：

1. 理解核心概念：Pipeline、Target、Release、Rollout 四者的關係
2. 搭配 Cloud Build：Cloud Build 做 CI，Cloud Deploy 做 CD
3. 善用審批機制：Production 環境一定要設定審批
4. 準備好回滾：知道如何快速回滾是關鍵

如果你的團隊已經在用 GCP，Cloud Deploy 值得認真考慮。它不會取代你對 CI/CD 的理解，但會讓實作變得簡單很多。

🔧 雲端部署搞不懂？ CI/CD 流程的設計涉及很多細節，從環境規劃到審批機制都需要考量。如果你在設定 Cloud Deploy 或規劃部署架構時遇到困難，讓 VibeFix 協助你規劃雲端方案，我們熟悉 GCP 生態系，能幫你建立穩健的部署流程。