CI/CD 是什麼：連續整合、連續交付與連續部署三個名詞的差異，為什麼測試才是核心而非推得更快
前面幾個章節陸續處理完伺服器、網域、安全性相關的基礎建設，這一節進入新的一章：CI/CD（持續整合／持續交付或部署）。這個主題乍看跟「全端工程師」沒什麼直接關係，但只要團隊規模一擴大，它就會變成不可或缺的一環。
為什麼規模一大，就不能沒有 CI/CD
如果一個系統只有一位開發者在維護，其實不太需要 CI/CD。但假設情境換成一百位開發者同時在同一個系統上開發新功能，問題就會浮現：正式環境上跑的到底是不是最新版本的程式碼？誰來確保這件事？如果做法是每個人各自把改動堆著，等到週五才一次性推上線、祈禱不要出包，這正是過去很長一段時間業界實際的做法，而這種做法風險極高。
CI/CD 這套概念，正是為了解決這個問題而生。CI 一律代表持續整合（Continuous Integration）：意思是所有改動都要盡可能頻繁地驗證、合併回主分支，而不是放著累積成一個動輒好幾萬行變動、開了兩個星期都沒合併的巨大分支。理想的做法是採用小而獨立（atomic）的改動，一旦出狀況也比較容易釐清問題出在哪裡。任何一位站點可靠性工程師（SRE，Site Reliability Engineer）都會告訴你，一旦系統規模夠大，CI/CD 幾乎是唯一可行的做法；反過來說，如果從來沒有在正式環境上跑過 git bisect 逐一排查問題根源，那其實算是幸運，因為那個過程通常相當痛苦。
連續交付 vs. 連續部署：容易搞混的兩個名詞
CI 之後接的到底是連續交付（Continuous Delivery）還是連續部署（Continuous Deployment），這兩個名詞光用聽的很容易被當成同一件事，但實際上有明確的差異：
- 連續交付（Continuous Delivery）：代表改動已經通過測試與驗證、隨時準備好可以上線，但不代表會自動推上正式環境
- 連續部署（Continuous Deployment）：代表通過所有測試與驗證流程的改動，會直接自動推上正式環境，正式環境隨時處於最新狀態
兩者之間該怎麼選，某種程度上是團隊自行決定的，也取決於改動本身的急迫性。以醫療應用這類高風險場景為例，通常不會選擇連續部署，因為一旦出錯，代價可能相當高，這種情況下比較適合連續交付：確保改動已經完全就緒，但仍然保留一道人工確認的關卡，再決定要不要真正推上正式環境。
不論是連續交付還是連續部署，兩者共同的基礎都是連續整合（Continuous Integration）：一切都建立在程式碼持續經過測試與驗證的前提之上。
CI/CD 真正的核心：測試，不是「推得更快」
很多人對 CI/CD 存在一個常見的誤解，以為它單純是為了讓程式碼上線的速度更快。但 CI/CD 真正的核心其實是驗證：確保程式碼隨時處於「已經準備好上線」的狀態，這樣當真正需要推上正式環境時，才不會對結果感到心慌。實務上常見的問題是，許多團隊把重心都放在建置（build）與部署（deployment）這兩個環節，卻忽略了測試才是 CI/CD 真正的核心與根基。
一個 CI/CD 的實際範例：Spinnaker
以 Netflix 內部使用的 Spinnaker 為例，這是一套相當強大的 CI/CD 工具：只要按一個按鈕，就能一次建立數百個設定完全一致的叢集，自動配好負載平衡器等各種基礎設施，等於是把前面章節手動走過一遍的伺服器建置、SSH 設定等繁瑣流程全部自動化。不過對於個人專案而言，Spinnaker 這類重量級工具通常是殺雞用牛刀，多數情境下根本用不到這種規模的解決方案，只有真正碰到相應規模的需求時，才會知道自己是不是真的需要它。
CI/CD 工具（不論是 Spinnaker 或其他系統）通常都會用管線（pipeline）的概念來組織整個流程：程式碼先推送到像 GitHub 這樣的儲存庫，接著依序跑過一輪又一輪的測試，每一個階段都是這條管線上的一個環節。測試的重要性怎麼強調都不為過，這也是為什麼很多人真心相信，業界普遍沒有寫足夠多的測試，而 CI/CD 之所以值得推崇，正是因為它強迫團隊必須用這種思維方式看待自己的程式碼。
接下來要做的事
理解了 CI/CD 的概念與重要性之後，接下來會實際動手做一個屬於自己的 CI/CD 管線，但不會用到 Spinnaker 這類複雜的重量級工具，因為對這門課的使用情境而言完全用不上這麼複雜的東西。事實上，要打造一個能運作的 CI/CD 管線，說穿了只需要幾行程式碼，加上一點耐心。
複習
連續整合（CI）的核心原則是什麼？
改動要盡可能頻繁地被驗證並合併回主分支，並且採用小而獨立、容易釐清問題的改動方式，一旦出狀況也比較好排查。
連續交付與連續部署最關鍵的差異是什麼？
連續交付代表改動已經準備好上線，但不會自動推上正式環境；連續部署則代表通過測試與驗證的改動，會直接自動推上正式環境。
CI/CD 中經常被忽略、但其實最根本的一環是什麼？
測試與程式碼驗證，而不只是把程式碼推得更快。確保程式碼在部署前經過充分測試，是整個流程真正的核心。
一個典型的 CI/CD 管線大致包含哪些步驟？
通常包含把程式碼推送到儲存庫，接著依序跑過多輪不同的測試，逐步通過各個驗證階段，才會進入是否部署的判斷。
為什麼有些公司會選擇連續交付，而不是連續部署？
對於像醫療應用這類高風險場景，人工驗證是避免潛在風險的關鍵，連續交付能讓改動在真正推上正式環境之前，保留一道人工審核的機會。
小測驗
CI/CD 中被認為最核心、最關鍵的一環是什麼？
測試與程式碼驗證典型的 CI/CD 管線一開始通常會經過哪些步驟？
把程式碼推送到儲存庫，接著跑過多輪測試為什麼醫療應用可能會偏好連續交付而不是連續部署？
為了在推上正式環境前保留人工驗證，降低風險此文章是 FrontendMasters 上的 Full Stack Fundamentals, v3 課程筆記
