什麼是 CI（持續整合）？
Continuous Integration（持續整合） 是在程式開發部署過程中建立的檢查流程，可以把這段當作產品特定指標的檢查點。
CI 的基本檢查項目
- commit 訊息檢查 + release information 產出
- 程式碼檢查（Linter）
- 程式碼品質檢測工具（如 SonarQube）
- 建構程式（Compiler Build）
- 容器映像檔更新與推送（Docker Hub / Harbor）
- 自動化測試
- 整合好 release 版本後打 release tag
為什麼需要自動化？
如果上述行為都是固定的，在不做自動化的狀態下就會變成每次都要手動執行，過程耗費的時間會不斷疊加。因此一般會在 Git 管理系統中使用自動化工具：
- GitLab:
.gitlab-ci.yml - GitHub: GitHub Actions
注意：在一般不需要打包的程式語言產品中會略過 compiler 步驟，但在 Java 這類需要打包的程式語言中是無法迴避的。
CI 的核心目標
在做 CI 流程控管時，主要重點是：萬一要做 roll back 的時候，要盡可能避免失誤造成災害及商業損失擴大。
什麼是 CD（持續交付/部署）？
CD 有兩種解釋：
- Continuous Delivery（持續交付）
- Continuous Deployment（持續部署）
兩者的交集是：因為上個階段 CI 的結果，產出可以部署的版本。CI 的重點在如何做出完整版本，CD 的重點在如何釋出這個版本。
不同階段的部署策略
Case 1：最基礎的手動部署
| 項目 | 說明 |
|---|---|
| 條件 | 無容器化、無資料分離、無 pipeline、無 K8s、無 Runner |
| 作法 | 手動到機器上執行 git pull，需要 compile 就直接在機器上執行 |
| 注意 | Load Balancer 不能在部署時轉導到該機器；有問題要現場修；修不好就 git checkout 上一版 |
Case 2：容器化但無資料分離
| 項目 | 說明 |
|---|---|
| 條件 | 容器化系統、無資料分離、無 pipeline、無 K8s、無 Runner |
| 作法 | 到機器上執行 docker pull 指定版本 |
| 注意 | 多台機器要一台台拉版；DB + file 都在 image 裡，拉版可能要 10 分鐘以上 |
| 好處 | 版本依據脫離 git hash；配合 Runner 退版只需按按鈕 |
Case 3：容器化 + 資料分離
| 項目 | 說明 |
|---|---|
| 條件 | 容器化系統、資料分離、無 pipeline、無 K8s、無 Runner |
| 作法 | 使用 image 部署，因資料分離容器較小 |
| 注意 | 多台機器仍需一台台拉版 |
| 好處 | 拉版 5 分鐘內可完成；為全自動化打地基 |
Case 4：加入 Pipeline
| 項目 | 說明 |
|---|---|
| 條件 | 容器化系統、資料分離、Pipeline、無 K8s、無 Runner |
| 作法 | 打包初始版本與運行版本分離 |
| 注意 | 用 GitLab/GitHub 控制 shell 做機器驗證、拉 image、執行 |
| 好處 | 雖有大量 env config，但比手動進機器好管理 |
Case 5：完整的 K8s + Runner
| 項目 | 說明 |
|---|---|
| 條件 | 容器化系統、資料分離、Pipeline、K8s、Runner |
| 作法 | 部署驗證透過 K8s YAML 控管，版本看 image tag |
| 注意 | K8s template 與 runner build 時間；開發者學習曲線 |
| 好處 | YAML 配置變得簡單 |
以上作法基本上可以用 GitLab/GitHub + Docker Hub 達成。另一派會用 Jenkins 做整個流程，但需要熟悉 Jenkins 文件與 Plugin。
總結
整段整理下來最重要的是：對整個系統的每個環節有所瞭解，才有辦法讓該行為轉為自動化。
自動化會不會有問題？肯定會有，但自動化造成的問題跟節省的時間比起來，真的是長痛不如短痛。