# CI/CD
## 重要性
- 在敏捷開發中，更快速可靠讓軟體變成可以交付
- 算是提高程式碼品質的一環（因為會提前檢查、統一團隊風格）

### Dev 簡略流程能做的事
如：在進入 deploy 之前，還會跑各種 testing
如：可能利用 container 封裝後上線，也會進行 scan
如：bundle size 也能在這個環節進行檢查

## Branch stragety
- 分支模型會影響 CI/CD pipeline
- 不同專案類型適合採用不同 flow
- Git flow (PoC / 小專案 / landing page)
- GitHub flow (Open Source / 大型專案)

> 可以思考哪邊會觸發 CI？哪邊想觸發 CD？（甚至有些團隊會習慣在 local 就進行 CI 檢視）

- 依照團隊資源（e.g. 是否有 GitHub actions, 用 Netlify 等第三方工具），可能在不同階段就有資源（流量 / 時間）跑 CI

### GitHub Flow
- 開發者獨立 fork 一份到自己的帳號，所以主要的 repo 會乾淨很多
- 要考量單一 branch 是否會要承擔太多工作（接受 stg, 產生 build, 上 prod, etc...）
- 可能還需要額外搭配 tag 觸發 CD

### GitLab Flow

- 主要有 main / dev / feature 三條分支
- 習慣直接開出一條 feature 後，對它發 PR，再讓這條 feature 進 dev

### TBD
- 每次開 PR 都觸發 CI，且 build 一次版本，但不 deliver
- 多開一條分支且有 tag，再拿 build 出的版本去 deliver，做一次 release
- 會有大量 feature toggle 去隱藏還沒進 release 的東西
- 每次 release 都是一條新的 branch（可以在不需要的時候再刪掉）

## CI 五大類型
> 除了第一個，其他工具的順序 / 時機都可以自行決定
- git 指令: 下不同指令去跑 script (e.g. husky 跑 pre-commit)
- Code quaility: Push PR 後檢查 (e.g. CodeRabbit)
- Linter
- Danger warning (e.g. SonarQube)
- Tests

## CI/CD implement
- 避免寫程式碼，而是單純用 shell 呼叫執行，或採用 Makefile
- 避免寫程式碼是因為非常難 debug
- 解耦合：像前端可以不用依賴 package manager

## 部署方式
- `滾動部署`：慢慢讓不同 cluster 都更新到新版本
- `藍綠部署`：直接透過設定 load balancer 去控制用戶到不同功能（e.g. 以地區分開）
- `金絲雀部署`：少部分比例的 user 送去新版本，確定沒問題再全部進去

## FAQ
- Docker 在前端有什麼應用？
- 讓服務能事前 build 起來跑測試
- 當然還是看專案複雜度，會影響到 infra 怎麼建置，可能在 Netlify / cloudflare 有些東西想拉出來自己管
- 有綁定特定資料，需要區分
- yaml 如何測試？實際用虛擬環境跑一次
- GitHub actions 可以檢查（但 deps 太多可能還是錯誤）
- Jenkins 能跑檢查

- CI/CD implement 的 env（像有 API key） 該如何維護？
- GitHub 可以直接放 secret 的 env（Vercel / Netlify 也是類似的概念）