你有沒有遇過多人一起改程式，結果一合併就炸掉？
你可以把持續整合想成「大家改完都先回到同一個主幹，順便自動檢查」：每次提交都跑建置和測試，提早抓出衝突。
它很重要，因為團隊開發最怕版本彼此打架，持續整合能把問題往前推，在還小的時候就處理掉。
容易混淆
持續整合 vs 持續部署 vs 手動合併
持續整合：每次提交都自動建置和測試
持續部署：通過檢查後自動發布到環境
手動合併：靠人自己整理版本，很慢也容易漏
最關鍵的區別：持續整合重點在「合併後先驗證」，不是直接發版。
記住這句就好
每次合併都先驗證，問題才不會堆到最後。
實際案例
多人協作開發
前：大家各寫各的，最後一天才合併，常常互相衝突
後：每次提交都自動建置、跑測試、檢查格式，衝突早點被抓出來
模型服務維運
前：程式碼、設定和依賴不同步，部署常出錯
後：把測試與建置放進 CI 流程，讓每次改動都先通過檢查再進下一步
算法與應用
持續整合通常包含版本控制、建置、單元測試、整合測試和自動化檢查
在 AI 或 MLOps 團隊裡，它會和容器化、模型部署、機器學習維運一起使用
真正的價值是提早發現錯誤，讓主幹永遠保持可用
情境判斷
Q1（直覺題）： 團隊每天多次合併程式，並自動跑測試，這像持續整合嗎？
→ 像，這就是它的核心做法。
Q2（判斷題）： 只要有自動部署，就一定代表有持續整合嗎？
→ 不一定。自動部署是後一步，持續整合要先有自動建置與測試。
常見問題
持續整合一定要搭配持續部署嗎？
不一定，但兩者常一起出現。
CI 和 CD 的差別是什麼？
CI 偏重合併驗證，CD 偏重自動發布。
為什麼 CI 可以減少 bug？
因為它把錯誤提早暴露在小變更裡，而不是等到大版本一起爆。