前一篇我們已經完成 75% 的前置動作，就差 cloud build 幫我們把最新的映像檔部署到 GKE 服務對吧，這部分也非常簡便，我們在建構步驟中，加一段 kubectl 的 deploy 指令就可以了。

呼叫 kubectl 來更新部署資源的步驟

語法

steps:
  - name: 'gcr.io/cloud-builders/kubectl'
    args:
    - set
    - image
    - deployment
    - [DEPLOYMENT-NAME]
    - [CONTAINER]=gcr.io/[PROJECT-ID]/[IMAGE]:[TAG]
    env:
    - 'CLOUDSDK_COMPUTE_ZONE=[COMPUTE-ZONE]'
    - 'CLOUDSDK_CONTAINER_CLUSTER=[CLUSTER]'

上面有五個變數要依據實際情況替換掉

• PROJECT-ID：GCP 專案的專案 ID
• IMAGE，映像檔的名稱及 TAG
• CLUSTER：叢集名稱，例如 k8s-cluster
• COMPUTE-ZONE：指定的區域，例如 asia-east1-a
• DEPLOYMENT-NAME：部署資源名稱，例如api-deployment

實際使用情況

steps:
  - name: 'gcr.io/cloud-builders/kubectl'
    args:
      - set
      - image
      - deployment
      - api-deployment
      - api-server=gcr.io/$PROJECT_ID/api-server:ci-$_NODE_ENV-$SHORT_SHA
    env:
      - 'CLOUDSDK_COMPUTE_ZONE=asia-east1-a'
      - 'CLOUDSDK_CONTAINER_CLUSTER=k8s-cluster'

如果專案是走 github flow 的開發模式，只有一條 master 分支，通常你不會希望程式碼 merge 進 master 就觸發自動部署的程序。又或者 production 環境的建置步驟跟 beta 環境的建構步驟差異太大，我們可以直接維護兩份檔案，例如 cloudbuild-beta.yaml 跟 cloudbuild-prod.yaml。cloudbuild-beta.yaml 設定下面這段自動部署的步驟，cloudbuild-prod.yaml 的部分則不設定也是可以。

如果專案是走 git flow 的開發模式的話，就更簡單控制，共用 cloudbuild.yaml 一個觸發點設定在 master 分支更新時，另一個觸發點設定在 develop 分支更新時，就可以了。基本上步驟 (steps) 都可以你的實用情境自行調整，這部分有很大的彈性。

資料來源 / 延伸閱讀

• 建構、測試和部署成果
• Continuous Deployment with Cloud Build