CI/CD 是什麼? 為什麼要 CI/CD?
2024年1月29日
CI/CD 是由 CI (Continuous Integration 持續整合) 以及 CD (Continuous Delivery/Deployment 持續交付/部署) 兩個字所組成。 雖然現在部分公司都有專門的 DevOps 工程師會負責處理 CI/CD，但許多公司仍是仰賴負責開發的工程師，例如前端、後端、全端工程師來負責處理。
在接下來三篇內容，我們會聊前後端工程師都需要知道的 CI/CD 基礎概念。在這一篇文當中，我們會先來聊「為什麼要有 CI/CD」。當你能更清楚理解某個技術或工具背後的脈絡，會對該技術或工具更有感。
為什麼要有 CI/CD
假如從歷史的角度來看，CI/CD 是在軟體開發史中，相對新的一個詞。這個詞彙的出現，是因為軟體開發模式改變。假如大家還有印象，在以前軟體還是用光碟片來安裝的時期，軟體的更新都是一次大版本的更新。對於開發者來說，是一次把完整的功能都做完、測試完，才會上線交付給使用者。
但是在時代變化下，近年來軟體開發有了改變，最有名的是 2001 年時，在軟體開發業界有 17 位資深專家，齊聚一堂發佈了敏捷宣言(The Agile Manifesto) 倡議，進而衍伸出後來的敏捷開發，而 CI/CD 也可說是這之後出來的詞彙。
敏捷宣言十二項原則
- 我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。
- 竭誠歡迎改變需求，甚至已處開發後期亦然。 敏捷流程掌控變更，以維護客戶的競爭優勢。
- 經常交付可用的軟體， 頻率可以從數週到數個月， 以較短時間間隔為佳。
- 業務人員與開發者必須在專案全程中天天一起工作。
- 以積極的個人來建構專案， 給予他們所需的環境與支援， 並信任他們可以完成工作。
- 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
- 可用的軟體是最主要的進度量測方法。
- 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。
- 持續追求優越的技術與優良的設計， 以強化敏捷性。
- 精簡 ── 或最大化未完成工作量之技藝 ── 是不可或缺的。
- 最佳的架構、需求與設計皆來自於能自我組織的團隊。
- 團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。
可以看到，在這個宣言下，軟體開發不再是一次完成一整包後才交付，而是「及早」交付，且開發者需要持續接收回饋，根據持續演進與變化的需求持續地開發。在這個概念下，我們需要一個能夠落地的具體方式，而 CI/CD 正是落地的手段之一。
CI/CD 定義
而 CI/CD 可以定義如下：
CI 是持續整合，意思是讓多個開發者，能夠共同在同個程式碼庫中開發不同的新功能，然後能夠持續整合到某個分支上面。之所要持續做這件事，是因為開發不同功能時，程式碼可能會有衝突，而持續地整合就能及早化解衝突。在 CI 的流程中，也會有自動化測試與建構，來避免等要上線前一次合併才發現有測試跑不過，或者建構有錯誤。
CD 則是持續交付/部署，在整合完後有自動化的部署流程。最理想的狀況，是當開發者把程式碼合併後，就會開始整合、測試，最終部署，整個流程不需用有人工介入，一切自動化完成，新的功能就會到最端使用者手上。
總的來說，CI/CD 的出現，是軟體開發往敏捷發展的脈絡下而生的一種手段，透過 CI/CD 我們可以自動化地完成程式碼整合、交付/部署，讓開發者可以專注在開發上。
讀到這可能對於具體來說，CI/CD 的整個流程該長什麼樣子，仍覺得很模糊。我們在下一篇會進一步討論。
補充說明: CI/CD 與 DevOps 的關係？
可能有讀者會問 CI/CD 與 DevOps 的關係。在爬梳這段歷史時，看到 DevOps 約是 2008 - 2009 年左右被提出；而 CI/CD 則是更早之前就有，只是後來才逐漸在業界普及。目前 CI/CD 是 DevOps 中的重要元素。可以在 Atlassian 這篇介紹看到，建置 CI/CD 流程是 DevOps 工程師的重要能力之一 連結 ，但要成為 DevOps 工程師，還需要有其他技能。
