By signing in, you agree to 古古的後端筆記's terms of service and privacy policy.
By signing in, you agree to 古古的後端筆記's terms of service and privacy policy.
古古
2025/05/05
大家在工作上可能常常會聽到 CI/CD、持續集成、持續部署…等等的名詞，但是卻不清楚這些名詞背後所代表的意義是什麼，因此這篇文章我們就來介紹一下，到底什麼是 CI/CD，以及他們之間的區別吧！
所謂的 CI/CD，他其實要拆分成兩個名詞來看，分別是 CI 和 CD：
所以雖然 CI 和 CD 長得很像，但是他們實際上所負責的是完全不同的流程！所以接下來我們就分別來看一下，CI 到底是負責什麼部分、而 CD 又是負責哪些部分。
所謂的 CI，就是指「計畫需求、實作程式、建置程式、測試程式」這四個步驟的統稱，而 CI 的終極目標，就是要讓這四件事可以被「自動化」執行，重點在「自動化」。
舉例來說，不管你是前端工程師、後端工程師、還是 Android/iOS 工程師，只要你的工作內容是「寫程式完成客戶的需求」（客戶可以是企業用戶，也可以是一般使用者），那麼你就是屬於開發者（Developer），而 Developer 的日常任務，其實就是大家常常在做的釐清需求、寫程式、測試程式而已。
所以 CI 並不是一個什麼新的流程，他只是希望可以把 Developer 日常的工作整合在一起，讓大家在「釐清需求 → 寫程式 → build code → 測試程式」這段路可以做得更順暢一點而已。
因此在 CI 的流程中：
因此大家也可以觀察一下，當你 push code 到你們公司的 GitHub、GitLab、BitBucket 等…雲端時，常常就會觸發一些 job 去 build code、去執行單元測試，而這些自動化執行的 job，其實都是 CI 的一環！！
也因為有了這些自動化 build code、自動化執行單元測試的 job，所以我們作為 Developer 不僅可以省去反覆手動操作的時間，也可以確保我們所撰寫的程式是已經被驗證過的，不會 merge 一份有問題的程式回 master branch。
所以到這裡，CI 的任務就完成了，因此簡單來說，CI 只要好好守護 Developer 們能夠把程式 build 完、把測試程式 run 完，CI 就功成身退了，接下來就是要進到 CD 的戰場了！
在我們進入 CD 的介紹前，大家可以先回想一下，你作為 Developer（前後端均可），是否還記得當你的 Pull Request 被 merge 之後，到底發生了什麼事嗎？如果你沒辦法很明確的說出後續每一個步驟在幹嘛，其實是非常正常的，因為「部署程式」這件事情，在職責上確實不歸 Developer 管。
一般在分工比較細的大公司來說，會將工程師區分成兩種人：Developer（開發工程師）和 Operations（維運工程師），其中 Developer 就是負責寫程式，達成 PM 的需求，而 Operations 則是負責部署程式，將 Developer 寫的程式部署到 server 上，讓使用者可以真的用到這個程式。
所以所謂的 CD，就是指 Operations 中的「發佈程式、部署程式、維運程式、監控程式運行狀態」這四個步驟的統稱，而 CD 的終極目標，一樣是要讓這四件事可以被「自動化」運行（這裡的自動化有一點微妙的差別，等等會介紹）。
因此在 CD 的流程中：
所以在 CD 的流程中，可以看到幾乎全部都是在做部署程式、維護 server 的相關操作，而這裡擴展下去就可以講非常非常廣了。
舉例來說，如果今天 server 選擇部署在 AWS 上，那麼如何更好的管理和運用 AWS 上的服務，就是 CD 要處理的部分，如果今天換成使用另一個雲端服務 GCP，那麼 CD 又會需要跟著改。
又或是說，假設今天是使用 Docker + Kubernetes 來部署程式，那麼如何打包 image、如何設定環境變數、如何使用 Kubernetes 調度 pod…等等，這些也是 CD 要處理的部分。
因此 CD 在玩法上可以說是更加的多樣化，追求的已經不僅僅是「把程式弄到 server 上去 run」這麼簡單而已，而是要追求「又快、又好擴展、又安全、又省錢」這種巔峰造極的境界了。
也因為如此，近幾年的部署流程其實也是各種飛速發展，其中最熱門的大概就是 Docker + Kubernetes 這類的容器化部署了，大家如果對這方面有興趣的話，可以參考我之前寫的 Docker 介紹，或是搜尋網路上各位大大們的 Docker 教學。
反正總而言之，CD 的任務就是要守護 Operations（維運工程師），讓維運工程師可以用最有效率的方式去部署和管理 server，同時也努力幫老闆省下最多的成本就對了！
了解了 CD 的概念之後，這裡也補充一下前面提到的「有點微妙的自動化」的部分。
在 CD 中，又可以細分成 Continuous Delivery（持續交付）和 Continuous Deployment（持續部署），他們兩個之間的差別就在於「部署到 production 正式環境這一步，是否需要人工手動操作」。
像是在前面的 CI 和 CD 的介紹中，一直有提到 CI 和 CD 的終極目標是「自動化」執行，但是會不會自動化過了頭，反而導致我們所交付的程式有問題呢？
舉例來說，假設當你所寫的程式被 merge 回 master branch 之後，假設就這樣自動化一路部署到 production 環境，中間完全沒有任何人再對他進行壓力測試、或是沒有進行服務的整合測試，可能就會出現意料之外的問題。
還有一個問題是，有時候功能的發佈是會需要搭配商業策略的，譬如說 iOS 的新功能常常會在 iPhone 發表會上宣布，這就是一種為了商業策略而延遲發版的行為。
因此一般在實務上，Continuous Delivery（持續交付）會是比較常見的做法（即是部署到 production 環境時需要人工手動操作），並且在 CI/CD 流程中的 CD，在正式的定義上也是指 Continuous Delivery（持續交付）的意思。
所以總結上述的介紹，所謂的 CI/CD 其實是指 CI 和 CD 這兩個不同的流程：
所以透過 CI 和 CD 的輔助，Developer 和 Operations 就可以在各自的流程中加快效率，進而達到「持續寫程式 → 持續集成程式 → 持續發版 → 持續交付 → 持續監控程式運行狀態 → 回頭繼續寫程式」的完美循環了！！！
PS: 注意看上面這張圖，遠看他其實就是一個無限大的符號 ∞，表示 CI/CD 是一個能夠無限運行下去的完美循環。
了解了 CI/CD 的概念之後，最後我們再來加碼補充一下什麼是 DevOps 吧！
其實 DevOps 這個職位是在 CI/CD 出現之後才興起的職缺，因為在 CI/CD 的流程中，Developer（開發工程師）和 Operations（維運工程師）是需要非常緊密的合作，才能夠達到最高的效率的。
舉例來說，如果 Operations 在後期的部署階段需要使用 Docker + Kubernetes 來部署，那麼 Developer 在前期就需要將程式盡可能地縮小，配合容器化的概念來實作程式，因此即使後面的部署流程和 Developer 沒有關係，但是 Developer 在開發上仍舊會被 Operations 影響，需要互相配合。
而 Operations 其實也是會反過來被 Developer 影響，像是如果 Developer 亂切服務、每個專案的設置都不一樣…等等，這些也是會造成 Operations 在後期的部署和管理上的困難。
因此這時候，就有人提出了一個想法：如果我們雇用一個超超超級強的人，他又懂 Developer 又懂 Operations，既會寫 code 又會部署，這樣他是不是就可以一人分飾兩角，在寫 code 時就預先避免掉後期部署可能會造成的影響、並且在後期部署時也不要反向影響 code 的架構，這樣不就天下太平了嗎？
沒錯，就是因為這個想法，所以 DevOps 這個職位就誕生了（DevOps 即是 Developer + Operations 的組合字，左半邊的 CI 是 Dev，右半邊的 CD 是 Ops）。
所以對於 DevOps 來說，他真的是包山包海，什麼都來一點，左手寫 code 右手部署，DevOps 就是 Developer 團隊和 Operations 團隊的橋樑，由他來串起整個 CI/CD 的全貌。
不過當然啦，即使上面的願景很好，但實際在工作中每個 DevOps 專精的領域還是會有點不太一樣（有的比較會寫 code、有的比較會部署），目前台灣比較常見的 DevOps 好像都是偏部署的居多，這方面我也還在學習中，如果有更多內容後續再和大家分享～
這篇文章我們先分別介紹了 CI 和 CD 的流程是什麼、以及他們各自要守護的人是誰，並且也補充了 DevOps 職位的存在意義，希望可以讓大家對 CI/CD 有更多的認識。
如果你對後端技術有興趣的話，也歡迎免費訂閱《古古的後端筆記》電子報，每週二為你送上一篇後端技術分享，那我們就下一篇文章見啦！
補充：我開設的 Spring Boot 零基礎入門、Spring Security 零基礎入門、GitHub 免費架站術 已在 Hahow 平台上架啦！輸入折扣碼「HH202505KU」即可享 85 折優惠。