CI 管品質，CD 管交付 — 自動化不是奢侈品，是生存必需品。
先講結論
CI（持續整合）確保每次提交的程式碼品質過關；CD（持續交付/部署）確保品質過關的程式碼能順利上線。自動化會不會有問題？肯定會，但跟手動出錯比起來，真的是長痛不如短痛。
CI 在做什麼？
CI 就是在程式碼合併之前建立的檢查流程。你的程式碼要通過以下關卡才能進入下一階段：
- Commit 訊息格式檢查
- 程式碼風格檢查（Linter）
- 程式碼品質檢測（SonarQube 之類的）
- 編譯打包（Java 等需要 compile 的語言）
- 自動化測試
- 容器映像檔建立和推送
這些事情如果每次都手動做，累死不說，遲早會漏掉。所以用自動化工具：GitLab 用 .gitlab-ci.yml，GitHub 用 GitHub Actions。
CI 的核心目標其實不是「讓部署變快」，而是萬一要 rollback 的時候，盡可能避免失誤造成災害擴大。
CD 分兩種
- Continuous Delivery（持續交付）：自動跑完 CI 後，產出可部署的版本，但上線需要人手動觸發
- Continuous Deployment（持續部署）：CI 過了就自動上線，完全不用人介入
CI 的重點在「如何做出完整版本」，CD 的重點在「如何釋出這個版本」。
部署成熟度五級
你的團隊在哪一級？
Level 1 - 手動部署：直接 SSH 到機器上 git pull，需要 compile 就在機器上跑。Load Balancer 不能在部署時轉導到該機器。修不好就 git checkout 上一版。聽起來就很刺激對吧。
Level 2 - 容器化但沒分離：用 docker pull 指定版本部署。DB + file 都在 image 裡，拉版可能要 10 分鐘以上。多台機器要一台台拉。
Level 3 - 容器化 + 資料分離：因為資料分離，容器變小了，拉版 5 分鐘內搞定。這一步是全自動化的地基。
Level 4 - 加入 Pipeline：打包和運行分離，用 GitLab/GitHub 的 Pipeline 控制部署流程。雖然 env config 很多，但比手動進機器好管理太多了。
Level 5 - K8s + Runner：部署全靠 K8s YAML 控管，版本看 image tag。學習曲線比較陡，但到了這一級基本上就是全自動了。
我的建議
對整個系統的每個環節有所瞭解，才有辦法讓它轉為自動化。如果你連手動部署的步驟都搞不清楚，自動化只會讓事情更糟。先手動做一遍，搞懂每個步驟，再來想自動化。
「我覺得手動比較保險」— 這句話通常出自從來沒被手動部署搞過的人。自動化是條不歸路，但你不會想回頭。
延伸閱讀
- Release 流程 — 具體的 release 操作步驟
- Release 管理 — 版本發佈的完整策略
- 泛用 Git 流程 — 對應的 Git 分支策略
- CommitLint 規範 — commit 訊息規範