CI/CD 的架構師視角
CI/CD 不只是開發團隊的事——對架構師而言，它是交付可靠性的關鍵基礎設施。一條設計良好的流水線能同時提升速度、安全性和穩定性；反之，混亂的部署流程往往是生產事故的根源。
Google Cloud 推崇以 DORA 指標（DevOps Research and Assessment）衡量軟體交付效能，PCA 考試也經常圍繞這些指標設計情境題：
| DORA 指標 | 說明 | 精英團隊基準 |
|---|---|---|
| 部署頻率 | 多常將程式碼部署至生產環境 | 每天多次按需部署 |
| 變更前置時間 | 從 commit 到上線的時間 | 少於一天 |
| 平均復原時間（MTTR） | 從事故發生到服務恢復的時間 | 少於一小時 |
| 變更失敗率 | 導致服務降級的部署百分比 | 0–15% |
架構師的職責是設計讓這四項指標同時改善的系統——而不是為了快而犧牲穩定。
💡 考試小提示：當題目問「如何提高部署頻率同時降低變更失敗率」，答案通常指向自動化測試 + 漸進式部署 + 快速回滾機制的組合。
Cloud Build
Cloud Build 是 GCP 全代管的 CI/CD 服務，負責從原始碼到可部署產物的整個建置流程。
Build Triggers 與觸發機制
Cloud Build 支援多種觸發來源：
- Cloud Source Repositories — GCP 原生 Git 倉庫，與 IAM 深度整合
- GitHub / GitHub Enterprise — 透過 Cloud Build GitHub App 連接，支援 push、PR 和 tag 觸發
- 手動觸發 — 適合需要人為控制的部署場景，可搭配參數化建置
cloudbuild.yaml 核心結構
每個建置由一系列 steps 組成，每個 step 指定一個容器映像和要執行的命令。Substitution Variables（如 $PROJECT_ID、$COMMIT_SHA）讓同一份設定可跨環境重複使用，自訂變數以 $_ 前綴定義。
Private Pools
標準建置在 Google 代管的基礎設施上執行，但若需要存取 VPC 內的私有資源（如內部 Artifact Registry、資料庫），則需使用 Private Pools。Private Pool 的 worker 運行在你指定的 VPC 網路中，滿足網路隔離與合規需求。
Build Approvals
對於敏感環境的建置，可啟用手動核准（Manual Approval）。建置觸發後會暫停等待指定的審核者批准，確保關鍵變更經過人為確認。
Artifact Registry
Artifact Registry 是 GCP 的全代管產物管理服務，取代了舊版 Container Registry。它不僅支援 Docker 容器映像，還涵蓋多種語言套件：
- 容器映像 — Docker、OCI 格式
- 語言套件 — npm、Maven、Python（PyPI）、Go、Apt、Yum
- 遠端倉庫（Remote Repositories） — 作為公共 registry（如 Docker Hub、npmjs.com）的代理快取，降低對外依賴並提升建置速度
漏洞掃描
Artifact Registry 與 Container Analysis 整合，自動掃描推送的映像中已知的 CVE 漏洞。掃描結果可作為部署閘門的輸入——只有通過安全檢查的映像才能進入下一階段。
💡 考試小提示：題目提到「集中管理多種格式的軟體產物」或「需要代理公共 registry」時，答案是 Artifact Registry，而非已棄用的 Container Registry。
Cloud Deploy
Cloud Deploy 是 GCP 的持續交付服務，專注於跨環境的漸進式部署。它與 Cloud Build 形成明確分工：Cloud Build 負責 CI（建置與測試），Cloud Deploy 負責 CD（環境推進與發佈管理）。
交付流水線
Cloud Deploy 的核心概念是 Delivery Pipeline，定義產物從開發到生產的推進路徑：
- dev — 自動部署，快速驗證
- staging — 整合測試，模擬生產環境
- prod — 需要手動核准（Approval Gates），搭配漸進式發佈策略
部署目標
Cloud Deploy 原生支援部署至 GKE、Cloud Run 和 GKE Enterprise，每個目標環境可設定獨立的部署策略和核准流程。
Canary 部署與回滾
Cloud Deploy 支援 Canary 部署——先將新版本導入一小部分流量（如 10%），驗證穩定後再逐步擴大。若偵測到問題，可一鍵回滾至上一個已知良好的版本，MTTR 大幅縮短。
安全軟體供應鏈
軟體供應鏈安全是近年來最受重視的架構主題之一。GCP 提供完整的工具鏈來保護從原始碼到部署的每一個環節。
SLSA 框架
SLSA（Supply-chain Levels for Software Artifacts） 是 Google 主導的開源框架，定義了多個安全等級（SLSA v1.0 為 Build L1–L3），從基本的建置記錄到完全可驗證的來源證明（Provenance）。Cloud Build 在符合條件的受管理建置環境下可產出符合 SLSA Level 3 的來源證明（build provenance）。
Binary Authorization
Binary Authorization 是部署前的最後一道防線。它要求容器映像必須通過指定的認證（Attestation） 才能部署到 GKE 或 Cloud Run：
- 認證者（Attestor） — 定義誰有權簽署映像（如安全團隊、QA 團隊）
- 簽章映像（Signed Images） — 使用非對稱金鑰簽署，確保映像未被篡改
- 部署策略 — 只有攜帶所有必要認證的映像才能部署至生產環境
💡 考試小提示：當題目描述「確保只有經過安全審核的容器映像才能部署到生產環境」，答案是 Binary Authorization + Attestation。
部署策略比較
不同的部署策略適用於不同的風險承受度和業務需求。以下是 PCA 必考的四種策略：
| 策略 | 原理 | 停機時間 | 回滾速度 | GCP 實作方式 |
|---|---|---|---|---|
| 滾動更新 | 逐批替換舊版本實例 | 零停機 | 中等（需重新部署） | GKE Rolling Update（預設策略） |
| 藍綠部署 | 維護兩套完整環境，切換流量 | 零停機 | 極快（切回舊環境） | Cloud Run Revisions、GKE 雙 Deployment |
| Canary 部署 | 小比例流量導向新版本，逐步擴大 | 零停機 | 快（縮減 Canary 比例） | Cloud Deploy Canary、Cloud Service Mesh Traffic Splitting |
| 流量分割 | 按百分比分配流量至不同版本 | 零停機 | 快（調整百分比） | Cloud Run Traffic Splitting（原生支援） |
選擇原則：滾動更新適合常規發佈；藍綠部署適合需要即時回滾的關鍵服務；Canary 適合高風險變更的漸進驗證；流量分割適合 A/B 測試和灰度發佈。
SDLC 最佳實踐
Trunk-Based Development
Google 內部和業界精英團隊普遍採用 Trunk-Based Development——所有開發者向主幹分支（main/trunk）頻繁提交小型變更，搭配 Feature Flags 控制功能的啟用時機。這種模式避免了長壽命分支帶來的合併衝突，也讓 CI 流水線始終反映最新狀態。
環境推進策略
- 不可變產物（Immutable Artifacts） — 同一個映像從 dev 推進到 prod，而非每個環境重新建置
- 環境差異透過設定管理 — 使用環境變數、ConfigMap 或 Secret Manager 區分環境，而非修改程式碼
- Secret Manager 整合 — CI/CD 流水線中的機敏資訊（API 金鑰、資料庫密碼）統一透過 Secret Manager 注入，避免硬編碼在原始碼或建置設定中
Feature Flags
Feature Flags 讓部署（Deployment）和發佈（Release）解耦——程式碼可以先部署到生產環境但功能尚未對用戶開放，待驗證完成後再透過 flag 啟用。這大幅降低了發佈風險。
實戰情境
情境一：受監管產業的安全 CI/CD
背景：一家金融科技公司需要建立符合 PCI-DSS 合規要求的 CI/CD 流水線，確保每一次部署都可追蹤、可稽核。
架構決策：
- 原始碼託管於 Cloud Source Repositories，啟用 IAM 細粒度存取控制
- Cloud Build Private Pools 在專屬 VPC 內執行建置，網路與其他工作負載隔離
- 每次建置自動產出 SLSA Level 3 來源證明，記錄建置環境和輸入來源
- 映像推送至 Artifact Registry 後自動執行漏洞掃描，高危 CVE 自動阻擋
- Binary Authorization 要求安全團隊和 QA 團隊雙重簽章認證，未認證映像無法部署至 GKE
- 所有建置與部署日誌匯出至 Cloud Logging，搭配 BigQuery 實現長期稽核分析
情境二：多區域漸進式部署
背景：一個全球化 SaaS 產品需要將新版本安全地推送至三個區域（asia-east1、us-central1、europe-west1），任何區域出現問題都能快速回滾。
架構決策：
- Cloud Deploy 定義多階段交付流水線：dev → staging → prod-asia → prod-us → prod-europe
- 每個生產區域採用 Canary 部署策略（10% → 50% → 100%），搭配 Cloud Monitoring 的自訂指標監控錯誤率
- 區域間部署設定 Approval Gates，亞洲區驗證通過後才能推進至美國區
- Cloud Run 的流量分割功能實現精確的 Canary 流量控制
- 回滾策略：偵測到錯誤率上升時，Cloud Deploy 一鍵回滾至上一個穩定版本，影響範圍僅限單一區域
重點整理
- DORA 四大指標是衡量 CI/CD 成效的黃金標準——部署頻率、變更前置時間、MTTR、變更失敗率
- Cloud Build 負責 CI：建置觸發、cloudbuild.yaml 定義流程、Private Pools 滿足安全需求
- Artifact Registry 統一管理容器映像和語言套件，支援漏洞掃描和遠端倉庫代理
- Cloud Deploy 負責 CD：交付流水線定義環境推進路徑，支援 Canary 部署和核准閘門
- Binary Authorization + SLSA 構建安全軟體供應鏈，確保只有經過驗證的映像才能部署
- 部署策略各有適用場景——滾動更新、藍綠、Canary、流量分割需根據風險和業務需求選擇
- Trunk-Based Development + Feature Flags + 不可變產物是 SDLC 最佳實踐的三大支柱
下一步
在下一課中，我們將探討業務流程分析與成本優化，掌握 FinOps 實踐、GCP 計費模型與成本管理工具鏈，學習從業務角度進行架構成本優化。