CI/CD 與軟體開發流程

流水線的目標是降低變更風險

CI/CD 不是把手動指令搬進 YAML。好的交付流程，會讓小變更更容易通過檢查、更快到達使用者；出問題時，也能很快判斷影響並復原。

目前 DORA 用五個 software delivery metrics 觀察 throughput 與 instability：

• Change lead time。
• Deployment frequency。
• Failed deployment recovery time。
• Change fail rate。
• Deployment rework rate。

這些指標應針對同一個 application／service 長期觀察，不用拿一張「菁英團隊門檻」逼所有團隊追同一個數字。高風險醫療系統和行銷網站的發佈節奏本來就不同。真正要找的是流程裡最大的等待、返工和失敗來源。

把交付流程拆成六個責任點

一條容易稽核的流程通常包含：

1. Source：誰能提交、review 和合併？
2. Build：使用什麼乾淨環境，把哪個 commit 建成產物？
3. Evidence：tests、scan 和 provenance 記錄了什麼？
4. Artifact：推進的是哪個 immutable digest？
5. Deploy：誰能把 release 推到哪個 target？
6. Verify：怎麼判斷成功，失敗後回滾還是 fix forward？

把 CI 和 CD 分開管理，能避免 build service account 順便擁有 production admin，也能讓同一份已驗證產物在環境間推進。

Source：先處理信任邊界

Cloud Build 2nd gen repositories 可連 GitHub、GitLab、Bitbucket 的 cloud／enterprise 版本，也可依架構使用 Developer Connect 或 Secure Source Manager。Cloud Source Repositories 從 2024-06-17 起已不提供給新客戶，不應再當成新專案預設。

Repository connection 本身帶有 credential 和 webhook trust。設計時要確認：

• Push、pull request、tag 和 manual trigger 各能觸發哪一條 pipeline。
• 來自 fork 的不受信任程式碼，是否能讀 secret 或使用高權限 service account。
• Protected branch、required review、CODEOWNERS 和 signed commit 是否符合風險。
• Build config 的修改是否需要 platform／security owner review。

如果 PR 可以同時改應用程式和 cloudbuild.yaml，那麼「只有 pipeline 能讀 production secret」並沒有想像中安全。要限制哪些 trigger 能注入 secret、使用 private pool 或取得 privileged identity。

Cloud Build：每個步驟都要知道用誰的權限

Cloud Build 以 containerized steps 執行 build、test、scan 和 packaging。安全重點包括：

• 使用用途清楚的 user-specified service account，不依賴 default service account 的歷史行為。
• 只授予 build 所需 Artifact Registry、log 和 source 權限；部署權限交給 CD 階段。
• 以 Secret Manager 提供必要 secret，避免寫進 substitution、image layer 或 build log。
• 固定 builder image digest／工具版本，並定期升級。
• 設 timeout、machine／pool capacity 和 log retention，避免失控 build。

Private pool 解決什麼？

Private pools 提供可自訂網路和 worker 環境，適合存取 private service、限制 egress 或符合特定 isolation 要求。它不是「較安全」的自動同義詞：pool 的 peering／PSC、DNS、egress、worker service account、machine image 和 patching 仍要設計。

不需要 private network 的一般 build，使用 fully managed pool 可能更簡單。需求應由 network path 和 compliance 驅動。

Artifact Registry：用 digest 推進同一份產物

Artifact Registry 支援 container image 與多種 package formats，也有 standard、remote 和 virtual repositories。Remote repository 可快取 upstream package；virtual repository 能用單一 endpoint 聚合 upstreams。這有助於控制依賴來源，但還要處理：

• Repository IAM 與 production／non-production 分隔。
• Upstream outage、package substitution 和 dependency pinning。
• Cleanup policy，避免誤刪仍在 production 使用的 digest。
• Vulnerability scanning 的 coverage、資料新鮮度和 exception workflow。

環境推進應引用 image digest，而不是可被移動的 latest tag。Dev、staging、prod 使用同一個 digest，只改環境 configuration，才能把 staging 驗證的內容和 production 部署的內容對上。

掃描結果也不是「只要有 High CVE 就永遠阻擋」。Policy 可以結合 exploitability、是否在 runtime path、修補可用性和 exception 到期日；高風險 exception 必須可追蹤。

Provenance 與 Binary Authorization

Software supply chain evidence 可以回答：產物來自哪個 source revision、由什麼 builder 和參數產生、經過哪些 policy。Cloud Build 在符合條件的 managed build 可產生 provenance；實際 SLSA build level 要依使用的 build type 與設定確認，不應替所有 Cloud Build 宣稱固定等級。

Binary Authorization 能在支援的 deployment target 檢查 policy 與 attestation。好的 attestation 代表一項可驗證事實，例如：

• 由受信任 builder 產生且 provenance 符合 policy。
• 指定 test suite 成功。
• Vulnerability policy 通過或 exception 尚未到期。
• Release 已由有權限的 approver 核准。

如果 build 成功就自動簽署、而 build service account 又能修改 policy，attestation 只剩形式。Signer、policy admin 和 deployer 應依風險分離，break-glass 也要留下理由並事後 review。

Cloud Deploy：管理 release 到 target 的推進

Cloud Deploy 以 delivery pipeline、target、release 和 rollout 管理 GKE、Cloud Run 等支援環境。CI 建好 artifact 後建立 release，再由 rollout 將它部署到各 target。

可搭配：

• Promotion approval 與 separation of duties。
• Canary phases、parallel／multi-target deployment。
• Pre／post deploy hooks 和 deployment verification。
• Automation rules 做排程 promotion、phase advancement、retry 或符合設定的 rollback。

Canary 並不會因為你寫了 10% → 50% → stable，就自動知道應用健康。要為每個 phase 定義可判斷的 verification，例如 error rate、latency、核心交易成功率和 log anomaly，並決定自動或人工 advancement。Cloud Run jobs 沒有 request traffic split，因此 Cloud Deploy 不支援對 job 做 canary。

回滾只處理可回復的部分

Cloud Deploy 的 rollback 會讓先前 release 回到 target；它不會自動復原已執行的 database migration、Pub/Sub event、付款或第三方 side effect。Release 設計要先處理相容性：

• Schema 使用 expand／migrate／contract，讓新舊版本能短期共存。
• Event schema 有 version 與 backward compatibility。
• Feature flag 的 state 和 application deployment 分開追蹤。
• 不可逆操作有補償或明確 fix-forward plan。

所以「一鍵回滾」是操作入口，不是整個系統狀態都能倒帶。

部署策略看的是故障隔離

• Rolling：分批替換 instance，資源需求較低；新舊版本會共存，capacity 和 compatibility 要測。
• Blue／green：保留兩套環境再切換，回切快但成本高，stateful dependency 仍共享時風險沒有消失。
• Canary：讓部分 traffic／instances 使用新版本，適合用 production signal 驗證；sample 要足夠代表真實使用者。
• Feature flag：把 deploy 和 release 分開，但 flag 也需要 owner、權限、到期清理和測試組合。

任何策略都不保證 zero downtime。Readiness、connection draining、capacity、client retry、schema 和 load balancer 行為共同決定使用者是否感受到中斷。

情境練習：支付 API 的安全發佈

1. GitHub protected branch 要求 payment owner 與 security-sensitive config owner review。
2. PR build 只跑不含 production secrets 的 tests；main build 用專用 service account 產生 image、SBOM 和 provenance。
3. Image 以 digest 存入受控 Artifact Registry；vulnerability policy 通過後產生 attestation。
4. Cloud Deploy 先推 staging，同一 digest 通過 integration、load 和 migration compatibility tests。
5. Production rollout 先 small canary，verification 觀察付款成功率、重複扣款、p99 latency 和 error budget burn。
6. Promotion 需要 release approver；deploy identity 不能修改 Binary Authorization policy。
7. Database migration 先 expand，舊版仍可運作；canary 失敗能回先前 release，不必逆向刪 schema。
8. Break-glass release 有短效權限、理由、告警和 incident review。

本課檢查清單

• DORA 現在使用五個指標；目的是找流程瓶頸，不是追固定排名。
• Source trigger 要區分 trusted branch 和 untrusted PR，避免外部程式讀取 secret。
• Build、artifact、deploy 和 policy identities 應按責任分離。
• 同一個 immutable digest 在環境間推進，不能每個環境重建。
• Provenance 與 attestation 要代表可驗證 evidence，不是流水線蓋章。
• Canary 必須有代表業務的 verification 與 advancement／abort 條件。
• Rollback 不會復原資料與外部 side effects，schema 和 event compatibility 要先設計。

延伸閱讀

• DORA software delivery performance metrics
• Cloud Build repositories
• Cloud Deploy overview
• Binary Authorization overview

下一步

下一課會把交付速度和基礎設施選擇轉成成本與業務指標，建立能看見、能歸屬、能安全採取行動的 FinOps 流程。