CI/CD 不等於一鍵上線：從程式合併到可回滾交付的 7 道關卡

專題編輯：Derek Chou｜AI 技術與架構編輯

下載 CI/CD 發布回執（ZIP，內含 CSV）

先說清楚 CI 與 CD 的差別

CI（Continuous Integration，持續整合）重點是頻繁整合程式變更，透過自動建置與測試提早發現相容性問題。CD 常用來表示 Continuous Delivery（持續交付）或 Continuous Deployment（持續部署）；兩者不是完全相同的制度。持續交付通常將版本維持在可發布狀態，是否正式上線可另設人員核准；持續部署則在符合既定條件後自動部署。應在團隊文件中寫清楚 CD 的意思，不要讓每個人各自理解。GitHub 官方將 Actions 定位為可自動化建置、測試及部署流程的平台。參考：GitHub Actions 介紹、Continuous deployment。

CI/CD 不是某一個特定網站或工具的名稱。GitHub Actions、其他 CI 平台或企業自建系統，都可以根據條件執行工作流。能否進入正式部署，取決於架構、憑證、執行權限與企業的發布政策。

七道關卡：每一道都要回答不同問題

第一道是來源控管：這次要交付哪一個 commit？誰有權建立 PR、審查與合併？第二道是建置：在指定版本和依賴下，能否一致地建立產物？第三道是自動測試：單元、整合與重要例外情境是否滿足最低標準？第四道是安全與權限：秘密是否存於核准的安全機制，第三方套件與部署權限是否受到管理？

第五道是發布批准：這次變更是否允許進入指定環境？第六道是部署與讀回：部署器有沒有回傳實際版本、服務識別碼和公開或內部網址？第七道是上線驗收與回滾：使用者能否正常看到預期結果、既有功能是否保留，失敗時能否恢復到已知可用版本？這七道是本文提出的管理框架，不是 GitHub 官方要求每個專案都配置完全相同的七個 job。

GitHub Actions 顯示成功，成功的是什麼？

GitHub Actions 的 workflow 由事件觸發，一個工作流可包含多個 jobs 與 steps，並交給 runner 執行。某個 job 成功，只代表該工作按其設定的條件完成；如果 workflow 根本沒有檢查正式網站的內容，綠色圖示就不能證明正式網站內容正確。這個差別在 AI 程式開發與自動出版情境中特別重要。

例如你讓流程處理文章或網站更新，至少要區分「程式碼檢查成功」、「產物封裝成功」、「部署 API 回覆成功」與「正式網址的實際內容讀回成功」。如果只驗證 POST 回應，卻不檢查使用者實際看到的頁面，可能把權限錯誤、快取、部署目標錯誤或內容缺漏留到上線後才被發現。

從開發分支到正式站，一份示意工作流

開發者修改 → 開 PR → 同儕審查
                  ↓
             CI 建置與測試
                  ↓
          分支保護與合併條件
                  ↓
          發布批准與版本封存
                  ↓
             部署至指定環境
                  ↓
        HTTP／DOM／功能讀回驗收
                  ↓
            成功紀錄或回滾

這是流程設計圖，不代表任何專案已照此部署。若網站承接訂單、金流與登入功能，更須確保回歸測試覆蓋這些受保護功能；若只是內部示範網站，批准流程可能較簡單，但不能藉簡化忽略資料與權限界線。

企業如何定義不可跳過的發布門檻？

可以將發布門檻寫成明確條件，而不是「工程師覺得沒問題」。例如指定測試必須全部通過、來源版本必須可追溯、正式部署使用最小權限憑證、部署後的頁面內容指紋與預期版本一致、重要表單提交流程可正常使用、回滾步驟可在必要時執行。哪些條件應自動判斷，哪些需人工批准，取決於風險與組織能力。

部署時仍需遵守秘密管理。不能把 WordPress 密碼、雲端金鑰寫入 YAML 或 GitHub 儲存庫；應使用平台提供的 Secrets 或企業核准的身分機制。也不該把 CI/CD runner 當成可對所有系統任意操作的管理者帳號。

一張可用的交付回執範本

若缺少任一重要回執，應寫出未驗證範圍，而不是把所有欄位填「完成」。尤其正式系統有使用者、訂單及其他持續變動資料時，回滾程式版本不等於能隨意回滾資料庫交易；資料遷移需要獨立設計。

真正的 CI/CD 成熟度，是減少「看似成功」

剛起步的團隊，可以先把 CI 用於基本測試與可重現建置；接著建立受控測試環境、發布簽核與部署紀錄；最後才根據實測品質決定是否進入更高程度的自動化部署。不要把「每小時發布一次」當作成熟度證明，若內容品質和授權門檻沒有解決，只會更頻繁地將錯誤送上線。

CI/CD 的價值不是省略人類責任，而是把原本仰賴個人記憶的交付規則，轉成能看見、能停止、能追查的工程制度。

有了 CI/CD，為什麼網站仍可能發布失敗？

在示意情境中，團隊設置了每次合併後執行的工作流。步驟依序下載程式碼、安裝依賴、執行測試、上傳網站檔案，最後顯示綠色勾號。主管打開正式首頁卻看不到修改。常見原因包括使用錯誤的部署目的地、快取尚未更新、部署流程只處理了程式而未處理媒體，或新版本根本沒有被服務端啟用。

要查清楚，必須拿出具體證據：這次提交的 commit、執行工作流的 run ID、產物 SHA-256、實際部署環境及部署服務回覆，最後讀回公開網址與預期內容。若讀回的是舊版本，不能只說「部署指令已成功」，而應標記 PUBLISHED_UNVERIFIED 或其他符合制度的阻擋狀態，直到原因被確認。

持續交付不應凌駕於編輯、法務與安全

當 CI/CD 管線用於文章、課程或其他含第三方素材的內容時，程式可以自動檢查檔案完整性、格式、重複提交、圖片是否存在、網址是否可讀，以及必要欄位是否填寫，卻不能獨立保證新聞事實無誤或法律風險為零。這些內容品質判斷必須在進入發布佇列之前完成；後段發布器只負責重新核驗完整性與部署，而不是第一次審稿。

例如一份企業專欄有一張外部下載的照片，即使技術上能透過 WordPress API 上傳成功，也不代表取得合法使用權。另一篇文章有錯誤統計數據，即使文章 HTML 可順利渲染，也仍應阻擋。自動化速度與內容真實性不是同一個指標。

什麼時候應採用手動發布批准？

可以依風險分級。一般的低風險內部文件，經充分測試後可自動部署；對交易系統、正式資料庫結構變更或敏感權限調整，應提高批准與可回退要求；對具有法律、權利或財務影響的內容，也應先完成獨立品質審查。人工批准不是低成熟度的象徵，而是可能符合風險成本的治理選擇。

如何避免佇列重跑造成重複上架？

自動化工作流可能因超時、網路中斷或排程重送而多次處理同一任務。發布器應先以內容鍵、來源版本與目標文章 ID 判斷是否已處理，對已存在的文章採原地更新策略，不能每次重新建立新的文章。若先前部署狀態不明，應先讀取 CMS 現況與發布回執，再決定重試或回滾；盲目重送可能產生重複頁、重複通知或資料不一致。

這種控制與部署層次相互補充。CI/CD 應負責穩定執行，發布契約應負責「什麼能被執行」，驗收機制則負責「執行結果是否滿足要求」。缺少任一層，將每小時排程改成每五分鐘一次，都不會從根本提升可信度。

參考資料

1. GitHub：Understanding GitHub Actions。
2. GitHub：Continuous Deployment。
3. GitHub：Actions Quickstart。

圖片與素材說明

封面為原創發布流程概念圖，非真實部署監控截圖。