什麼是 CI/CD？持續整合與持續交付簡單解說
CI/CD 是一種軟件發布方式：每一項程式碼改動都會自動建置、測試，並且——如果通過測試——準備發布或直接發布。**CI（持續整合）**指改動經常合併，並每次都由自動化測試檢查。**CD（持續交付或持續部署）**指通過測試的改動會被打包並推向用戶，過程中只需很少甚至完全不需要人手操作。
重點很簡單：在錯誤出現後的數分鐘內就將它捕捉到，而不是數星期後才由客戶發現。
用 AI 做 App 時，CI/CD 為何重要
AI 生成工具改動程式碼的速度很快。一個提示就可能影響十個檔案。這種速度固然很好，但如果對結帳頁面的一個改動悄悄弄壞了登入頁面，而你要到用戶來電郵投訴時才發現，那就麻煩了。
CI/CD 正是為此而設的安全網。流水線不會假設每次改動都沒問題，而是每次都執行同樣的檢查：
- App 還能不能無錯誤地建置？
- 自動化測試是否仍然通過？
- 程式碼是否符合專案的規則（型別、格式、安全檢查）？
只要任何一項檢查失敗，改動就會在到達用戶之前被攔下。程式碼改得越快，一項永不疲倦、不會跳過步驟的檢查就越有價值。
日常比喻
想像一間每天早上向各間店舖供應麵包的麵包店。
- 沒有 CI/CD 的話，每位師傅各自調整配方一星期，然後在星期五晚上把所有改動混在一起，希望麵包仍然膨脹。如果麵包沒有膨脹，沒人知道是誰的改動造成的。
- 有了 CI，每一個細小的配方改動都會立即烤一個試驗麵包，並檢查味道、重量和形狀。壞的改動當天就會被發現，而且你確切知道是哪一個。
- 有了 CD，通過檢驗的麵包會直接放上送貨車，每次都以同樣的方式包裝及貼上標籤，而不是有人凌晨五點手工裝箱。
檢驗不會令師傅變得更好，但它令他們犯的錯誤代價變得很低。
CI/CD 流水線如何運作
**流水線（pipeline）**是 CI/CD 服務在某事發生時（通常是有人把程式碼推送到 GitHub 等儲存庫時）自動執行的一連串步驟。典型的流水線如下：
| 步驟 | 發生什麼事 | 能捕捉什麼 |
|---|---|---|
| 1. 觸發 | 程式碼被推送，或開啟了拉取請求（pull request） | — |
| 2. 安裝 | 一部全新的機器下載程式碼及其依賴項目 | 缺少或損壞的套件 |
| 3. 建置 | App 被編譯或打包 | 語法及型別錯誤、損壞的匯入 |
| 4. 測試 | 執行自動化測試 | 不再運作的功能 |
| 5. 檢查 | 程式碼檢查（linting）、格式檢查、安全掃描 | 風格問題、已知有漏洞的套件、外洩的金鑰 |
| 6. 部署到預備環境 | App 被送到與正式環境相同的測試副本 | 只有在真實環境中才會出現的問題 |
| 7. 部署到正式環境 | App 上線，可以是自動的，也可以是經批核後才上線 | — |
每個步驟都在一部乾淨的機器上運行，而不是某人的手提電腦上，所以「在我的電腦上是可以運作的」再也不能作為藉口。如果某個步驟失敗，流水線便會停止，並通知作出改動的人。
這些步驟定義在與程式碼放在一起的設定檔中。例如在 GitHub Actions 中，它是儲存庫 .github/workflows 資料夾內的一個 YAML 檔案。
持續交付與持續部署
「CD」一詞有歧義，人們兩種用法都有：
| 持續交付 | 持續部署 | |
|---|---|---|
| 測試自動運行 | 是 | 是 |
| 發布版本自動打包 | 是 | 是 |
| 自動上線 | 否 — 由人按下「發布」 | 是 — 每項通過的改動都會上線 |
| 適合 | 大部分小型團隊、有付費用戶的 App | 測試覆蓋全面、並有監察機制的團隊 |
只有測試夠好，持續部署才行得通。如果你的測試沒有涵蓋結帳，持續部署就會毫不猶豫地把一個壞掉的結帳功能推上線。
實例：預約 App 的流水線
假設你有一個美容院預約 App，程式碼放在 GitHub 儲存庫中。你請 AI 生成工具「為首次光顧的客人加入九折優惠」。
- 改動被推送到新分支，並開啟一個拉取請求。
- 流水線開始運行。它安裝套件並建置 App——通過。
- 它執行測試。其中一項測試「回頭客需付全價」失敗：優惠被套用到所有人身上。
- 拉取請求顯示紅色叉號，改動無法合併。
- 你請 AI 修正。它推送修正版本；流水線再次運行，全部通過。
- 改動獲合併。流水線把它部署到**預備環境**，你可以在那裡試做一個測試預約。
- 你批准後，它便部署到正式環境。
如果沒有這條流水線，第 3 步的錯誤就會發生在你客人的錢包上。
重要詞彙
| 詞彙 | 意思 |
|---|---|
| 流水線（Pipeline） | 每次改動都會運行的一連串自動化步驟。 |
| 建置（Build） | 把原始程式碼轉換成可以運行的形式。 |
| 自動化測試（Automated test） | 檢查其他程式碼是否做到應有功能的程式碼。 |
| 拉取請求（Pull request，PR） | 一項擬議中的改動，合併前會由其他人（及流水線）審閱。參閱什麼是 GitHub。 |
| 分支（Branch） | 一條獨立的改動線，令進行中的工作不影響主要程式碼。 |
| 預備環境（Staging） | 你 App 的私人副本，與正式環境相同，讓你在用戶看到之前檢查改動。 |
| 正式環境（Production） | 用戶正在使用的上線 App。 |
| 回滾（Rollback） | 發布出錯時，退回到之前運作正常的版本。 |
| 綠色／紅色建置 | 一次流水線運行通過／失敗。 |
常見誤解
- 「CI/CD 就代表我的 App 經過測試。」 流水線只運行你擁有的測試。如果沒有測試，CI 只能證明 App 可以建置，僅此而已。請要求 AI 為最重要的流程編寫測試。
- 「CI/CD 只適合大公司。」 GitHub Actions 等託管工具只需一個簡短的設定檔即可設定，小型團隊經常使用。真正花功夫的是測試，而不是工具。
- 「自動部署即是無人檢查。」 好的流水線是加入檢查，而不是減少檢查。許多團隊仍會在正式上線前保留人手批核的步驟。
- 「流水線顯示綠色，就代表 App 能運作。」 這只表示自動化檢查通過。你仍應親自試用改動，最好是在預覽或預備環境中。
- 「CI/CD 可以取代備份。」 不能。一個通過測試的錯誤資料庫遷移，仍可能破壞真實資料。請保留備份，並確保有回滾的方法。
可以問你的 AI 生成工具的問題
- 「為註冊、登入及結帳編寫自動化測試，並向我展示如何執行。」
- 「設定一個 GitHub Actions 工作流程，在每個拉取請求上安裝依賴項目、建置 App 並運行測試。」
- 「在流水線中加入型別檢查及程式碼檢查，並在出現錯誤時令它失敗。」
- 「用淺白的語言解釋流水線每個步驟的作用。」
- 「如果部署中途失敗，會發生什麼事？我該如何回滾？」
- 「確認沒有把密鑰硬編碼在儲存庫中，也沒有在流水線日誌中印出。」
如果你的 App 使用 API 金鑰，流水線同樣需要它們——應儲存為 CI 工具中的加密機密，絕不可放在設定檔中。參閱環境變數與機密。
CI/CD 與 Mythex
Mythex 不會替你運行 CI 流水線，但它以自己的方式涵蓋了部分相同的需要：
- 檢查點。 每次代理程式成功完成一輪操作後，Mythex 都會儲存一個 git 檢查點；如果某項改動出錯，還原至此版本便會把專案回滾。參閱對話。
- App 測試。 輸入
/test，代理程式會像用戶一樣點擊你的即時預覽，並報告損壞的流程——在每次發布前都很有用。參閱App 測試。 - 發布是刻意的步驟。 改動會先在私人預覽中出現；只有當你再次發布時，公開 App 才會更新——這更接近持續交付，而非持續部署。
- GitHub 同步（Pro）。 把專案同步到 GitHub 儲存庫後，你可以加入自己的 GitHub Actions 工作流程，在每次推送時運行測試。參閱GitHub 與匯出。
如需上線前手動測試的清單，請參閱如何在上線前測試你的 App；至於版本控制，請參閱如何在 AI 生成的 App 中使用 Git。
常見問題
CI/CD 代表什麼？
CI 指持續整合（continuous integration）：每次程式碼改動都經常合併，並自動建置及測試。CD 指持續交付（continuous delivery）或持續部署（continuous deployment）：通過測試的改動會自動準備好發布（交付），或無需人手步驟便自動發布給用戶（部署）。
持續交付與持續部署有什麼分別？
在持續交付中，每項通過流水線的改動都已可以發布，但仍由人決定何時推上線。在持續部署中，每項通過測試的改動都會自動上線，中間沒有人手批核的步驟。
小型 AI 生成 App 需要 CI/CD 嗎？
第一天未必需要。只有少數用戶的小型 App，可以在預覽中測試，然後手動發布。當有數人同時改動程式碼、真正的客戶依賴這個 App，或你經常弄壞原本正常運作的功能時，CI/CD 就會發揮作用。
CI/CD 會用到哪些工具？
常見的有 GitHub Actions、GitLab CI/CD、CircleCI 和 Jenkins，以及各個託管平台內建的部署流水線。它們的基本工作相同：每當程式碼改動，就自動執行一連串步驟。