如果要把 GitHub Actions 接到 GCP, 我現在最不想再做的就是:
這樣一開始很省事, 但後面只要開始切 dev / prod, 風險和 debug 成本都會一起上升。
這篇整理我最後收斂出來的做法: 用 branch、workflow、service account 三層一起切最小權限。
這篇記錄一件我現在很常回頭看的事: 如果一開始 Terraform 只有一個 root, 後來才想補 dev / prod、補 shared 層、補 CI/CD 邊界, 到底該怎麼遷移才不會影響既有環境。
我最後的結論很簡單:
這篇記錄我把一套 Cloud Run + Cloud SQL 應用留在同一個 GCP project 裡, 但仍然把 dev 和 prod 切乾淨的做法。
重點不是 branch 命名, 也不是多建兩個 GitHub workflow 而已。真正要切的是 state、資源命名、secrets、執行身分、部署身分, 還有 workflow 控管。這幾層如果只漏一層, 最後就還是會互撞。
上一篇 講了 DDD 的概念跟 .NET MVC 的對比。這篇記錄實際在專案裡踩到的坑: aggregate boundary 怎麼畫、double-entry ledger 怎麼設計、event system 怎麼讓模組之間溝通
Aggregate 的規則聽起來很簡單 — 一組一定要一起存取的東西, 有一個 root entity 當入口。但實際畫 boundary 的時候, 很容易畫錯
在專案開發中第一次碰到 DDD (Domain-Driven Design)。之前寫過 .NET MVC, 也學過 Go, 發現很多概念其實跟已經知道的東西有關聯, 特別是 Repository Pattern。這篇記錄一下我怎麼從這些已有的認知去理解 DDD
