什麼是 CI/CD？持續整合與持續交付白話說明
CI/CD 是一種軟體交付方式：每一次程式碼變更都會被自動建置、測試，並在通過後準備發布或直接發布。**CI（持續整合）**表示變更會頻繁合併，而且每次都由自動化測試檢查。**CD（持續交付或持續部署）**表示通過檢查的變更會被打包，並在很少或完全不需人工介入的情況下推向使用者。
重點很簡單：在錯誤產生後幾分鐘內就抓出來，而不是等幾個星期後客戶才發現。
用 AI 開發時，為什麼 CI/CD 很重要
AI 建構工具能快速修改程式碼。一次提示就可能動到十個檔案。這種速度很好，直到有一天結帳頁面的修改悄悄弄壞了登入頁面，而沒有人注意到，直到使用者寄信給你。
CI/CD 正是為了這種情況而設的安全網。它不是寄望每次變更都沒問題，而是讓流水線每次都執行同樣的檢查：
- 應用程式在建置時是否仍然沒有錯誤？
- 自動化測試是否仍然通過？
- 程式碼是否遵守專案的規則（型別、格式、安全性檢查）？
只要任何一項檢查失敗，變更就會在到達使用者之前被攔下。程式碼變更越快，一個永遠不會疲倦、也不會跳過步驟的檢查就越有價值。
日常生活的比喻
想像一家每天早上都要供應麵包給商店的麵包坊。
- 沒有 CI/CD 時，每位師傅各自調整配方一整週，然後週五晚上大家把配方合在一起，祈禱麵包還能發起來。如果發不起來，沒有人知道是誰的改動造成的。
- 有 CI 時，每一次小小的配方調整都會立刻烤一條試做的麵包，並檢查味道、重量與形狀。有問題的改動當天就會被抓出來，而且你確切知道是哪一項。
- 有 CD 時，通過檢驗的麵包會直接放上配送車，每次都以同樣的方式包裝、貼上標籤，而不是有人在凌晨五點用手裝箱。
檢驗不會讓師傅變得更厲害，而是讓他們的錯誤付出的代價變小。
CI/CD 流水線如何運作
**流水線（pipeline）**是當某件事發生時，由 CI/CD 服務自動執行的一連串步驟——通常是有人把程式碼推送到 GitHub 之類的儲存庫時。典型的流水線大致如下：
| 步驟 | 發生的事 | 能抓出什麼 |
|---|---|---|
| 1. 觸發 | 程式碼被推送，或開啟了拉取請求（pull request） | — |
| 2. 安裝 | 一台全新的機器下載程式碼及其相依套件 | 遺失或損壞的套件 |
| 3. 建置 | 應用程式被編譯或打包 | 語法與型別錯誤、損壞的匯入 |
| 4. 測試 | 執行自動化測試 | 不再正常運作的功能 |
| 5. 檢查 | 程式碼檢查（linting）、格式檢查、安全掃描 | 風格問題、已知有漏洞的套件、洩露的金鑰 |
| 6. 部署到預備環境 | 應用程式被送到正式環境的測試副本 | 只有在真實環境中才會出現的問題 |
| 7. 部署到正式環境 | 應用程式上線——自動進行或經核准後進行 | — |
每個步驟都在乾淨的機器上執行，而不是某個人的筆電，因此「在我電腦上可以跑」不再是藉口。如果某個步驟失敗，流水線會停止，並通知造成變更的人。
這些步驟定義在與程式碼放在一起的設定檔中。例如在 GitHub Actions 中，它是儲存庫 .github/workflows 資料夾裡的一個 YAML 檔案。
持續交付與持續部署的比較
「CD」這個詞有歧義，人們兩種意思都會用：
| 持續交付 | 持續部署 | |
|---|---|---|
| 自動執行測試 | 是 | 是 |
| 自動打包發布版本 | 是 | 是 |
| 自動上線 | 否——由人點擊「發布」 | 是——每一個通過的變更都會上線 |
| 適合 | 大多數小型團隊、有付費使用者的應用程式 | 測試涵蓋率高、有完善監控的團隊 |
持續部署只有在測試做得好的情況下才行得通。如果你的測試沒有涵蓋結帳流程，持續部署就會毫不猶豫地把壞掉的結帳功能推上線。
實例：使用流水線的預約應用程式
假設你有一個美髮預約應用程式，程式碼放在 GitHub 儲存庫中。你請 AI 建構工具「為首次消費的客戶加上 10% 折扣」。
- 變更被推送到一個新分支，並開啟一個拉取請求。
- 流水線開始執行。它安裝套件並建置應用程式——通過。
- 它執行測試。其中一項測試「回頭客應付全價」失敗：折扣被套用到每一位客戶身上。
- 拉取請求顯示紅色叉號，這項變更無法合併。
- 你請 AI 修正。它推送了更正；流水線再次執行，全部通過。
- 變更被合併。流水線將它部署到**預備環境（staging）**，你可以在那裡試做一次預約。
- 你核准後，它部署到正式環境。
如果沒有這條流水線，第 3 步的問題就會直接發生在客戶的荷包上。
關鍵名詞
| 名詞 | 意義 |
|---|---|
| 流水線（Pipeline） | 每次變更都會自動執行的一連串步驟。 |
| 建置（Build） | 把原始碼轉換成可以執行的東西。 |
| 自動化測試 | 用來檢查其他程式碼是否按預期運作的程式碼。 |
| 拉取請求（Pull request, PR） | 一項提議中的變更，在合併前會由他人（與流水線）審查。請參閱什麼是 GitHub。 |
| 分支（Branch） | 獨立的一條變更線，讓進行中的工作不會影響主程式碼。 |
| 預備環境（Staging） | 與正式環境相同、專供私下檢查變更的應用程式副本，讓使用者看到之前先驗證。 |
| 正式環境（Production） | 使用者實際使用的上線應用程式。 |
| 回滾（Rollback） | 當發布出錯時，退回先前可正常運作的版本。 |
| 綠燈／紅燈建置 | 一次流水線執行通過／失敗。 |
常見的誤解
- 「CI/CD 代表我的應用程式有經過測試。」 流水線只會執行你擁有的測試。如果沒有測試，CI 只能證明應用程式可以建置——僅此而已。請要求你的 AI 為最重要的流程撰寫測試。
- 「CI/CD 只適合大公司。」 GitHub Actions 這類代管工具只需一個簡短的設定檔就能設定完成，小型團隊也經常使用。真正耗費心力的是測試，而不是工具。
- 「自動部署代表沒有人檢查任何東西。」 好的流水線是增加檢查，而不是減少檢查。許多團隊在正式上線前仍會保留人工核准的步驟。
- 「流水線顯示綠燈，代表應用程式可以正常運作。」 這只代表自動化檢查都通過了。你仍然應該親自試用這項變更，最好是在預覽環境或預備環境中。
- 「CI/CD 可以取代備份。」 不能。一個通過測試的錯誤資料庫遷移，仍然可能破壞真實資料。請保留備份，並準備好回滾的方法。
該向你的 AI 建構工具要求什麼
- 「為註冊、登入與結帳撰寫自動化測試，並向我展示如何執行它們。」
- 「設定一個 GitHub Actions 工作流程，在每個拉取請求上安裝相依套件、建置應用程式並執行測試。」
- 「在流水線中加入型別檢查與程式碼檢查工具，並在出現錯誤時讓它失敗。」
- 「用白話解釋流水線的每個步驟在做什麼。」
- 「如果部署執行到一半失敗會怎樣？我該如何回滾？」
- 「檢查儲存庫中或流水線日誌中是否有寫死的機密資料。」
如果你的應用程式使用 API 金鑰，流水線也需要它們——應儲存在 CI 工具中的加密機密裡，絕不能放在設定檔中。請參閱環境變數與機密。
Mythex 中的 CI/CD
Mythex 不會替你執行 CI 流水線，但它以自己的方式滿足了其中幾項相同的需求：
- 檢查點。 每一次代理程式成功完成一輪作業後，Mythex 都會儲存一個 git 檢查點，如果某項變更出錯，還原到此點可以將專案退回。請參閱對話。
- 應用程式測試。 輸入
/test，代理程式會像使用者一樣在你的即時預覽中操作，並回報壞掉的流程——在每次發布前都很有用。請參閱應用程式測試。 - 發布是刻意的步驟。 變更會先出現在私人預覽中；只有當你再次發布時，公開的應用程式才會更新——這比較接近持續交付，而不是持續部署。
- GitHub 同步（Pro）。 將專案同步到 GitHub 儲存庫後，你可以加入自己的 GitHub Actions 工作流程，在每次推送時執行測試。請參閱GitHub 與匯出。
若想了解上線前需要手動測試哪些項目，請參閱如何在上線前測試你的應用程式；若想了解版本控制，請參閱如何在 AI 開發的應用程式中使用 Git。
常見問題
CI/CD 是什麼的縮寫？
CI 代表持續整合（continuous integration）：每次程式碼變更都會頻繁合併，並自動建置與測試。CD 代表持續交付（continuous delivery）或持續部署（continuous deployment）：通過測試的變更會自動準備好發布（交付），或在沒有人工步驟的情況下直接發布給使用者（部署）。
持續交付和持續部署有什麼不同？
在持續交付中，每一個通過流水線的變更都已可以發布，但仍由人決定何時正式上線。在持續部署中，每一個通過的變更都會自動上線，不需要人工核准。
我用 AI 開發的小型應用程式需要 CI/CD 嗎？
第一天不一定需要。只有少數使用者的小型應用程式，可以用預覽環境測試、再手動發布來應付。當有好幾個人同時修改程式碼、真正的客戶開始依賴這個應用程式，或你常常弄壞原本能正常運作的功能時，CI/CD 就會發揮價值。
CI/CD 常用哪些工具？
常見的工具包括 GitHub Actions、GitLab CI/CD、CircleCI 和 Jenkins，另外各家主機平台也有內建的部署流水線。它們的基本工作都相同：每當程式碼變動時，自動執行一連串步驟。