之前我們bff有更新 需要推上cloud run更版,
需要在本地進行build 再推image到gcp的registry後
跑 gcloud run deploy 更新cloud run的image

而今天要做的就是當codebase更新時觸發build和deploy
以POC來說 有更新就直接上版是最快的 就是CICD接著做,
但是以成熟產品來說 就會有版控, CI 與 CD也通常會分開來執行
當有更新時觸發CI(如更新main分枝 或是手動觸發), 有核准時才進行CD

在gcp的管理上 我比較常看到的是把環境和proj分開 也就是per env per proj
這樣在IAM授權 和budget管理也比較方便
但以服務來說 兩個proj還是對應到同一份codebase
只是CICD的trigger不同

各家的git flow可能有自己的考量
這裡我沿用當前團隊習慣的flow

我的主要分支是main

開發時會checkout feat/xxx
驗證時merge到staging 推送到staging cloud run

上線前把驗證過的feat/xxx merge回main, checkout出release/xxx 並上線

這裡staging分枝希望 有更新就跑完CICD, 方便測試流程
release則是觸發CI, 等待手動(approval)啟動CD

不過因為公司的測試環境proj是需要申請的

我就做示意 會觸發不同proj的build, deploy不另外開專案了

這裡會做的更新是terraform(cicd.tf)定義不同branch pattern會觸發的 cloud build與cloud deploy(ex. staging-cloudbuild.yaml)