持續部署 是什麼？
Continuous Deployment：持續部署 的完整解釋
自動化將通過測試的程式碼變更直接部署到生產環境的軟體工程實踐。
持續部署（Continuous Deployment）是現代軟體工程與 MLOps 流程中不可或缺的核心實踐。它建立在持續整合（Continuous Integration，CI）與持續交付（Continuous Delivery，CD）的基礎上，三者合稱 CI/CD 管線，是當代雲端原生應用與 AI 系統的標準運作模式。
一、基本概念與運作原理
持續部署的核心思想是：只要程式碼或模型的變更通過了預先設定的自動化測試套件，系統就會自動將這份變更推送到生產環境，整個過程無需任何人工干預。這與「持續交付」有所不同：後者只保證變更隨時可以部署，但實際部署動作仍由人工決策；而持續部署則將部署動作也自動化了。
從技術流程看，一次典型的持續部署循環包含以下步驟：開發者提交程式碼至版本控制系統（如 Git），觸發 CI 伺服器（如 GitHub Actions、GitLab CI、Jenkins）自動拉取最新程式碼，執行單元測試、整合測試、程式碼品質檢查，如果全部通過，自動化工具（如 ArgoCD、Spinnaker、Kubernetes 滾動更新）將新版本部署至正式環境，同時監控系統持續追蹤部署後的指標（錯誤率、延遲、回應時間），若有異常則自動回滾至上一個穩定版本。
二、在 MLOps 場景中的特殊意義
對於 AI 與機器學習系統而言，持續部署帶有特殊的複雜度。傳統軟體的「部署」通常只涉及程式碼；但 ML 系統的部署物件還包括模型權重、資料前處理管線、特徵工程邏輯、模型版本與設定檔。
MLOps 中的持續部署實踐通常需要搭配以下機制：
模型版本管理：使用 MLflow、DVC 或 Weights & Biases 追蹤每個模型版本的訓練超參數、資料集版本與評估指標，確保生產環境中跑的模型是明確記錄過的版本。
影子部署（Shadow Deployment）：新模型先以「影子」方式接收真實請求，但不對外回傳結果，只記錄預測值。工程師比較新舊模型的預測分佈後，確認無顯著偏差才正式切換流量。
金絲雀發布（Canary Release）：將少量流量（例如 5%）導入新模型，觀察生產指標是否惡化，再逐步擴大比例至 100%。這樣即使新模型有問題，受影響的使用者範圍也極有限。
A/B 測試整合：有時部署本身就是實驗的一部分，不同使用者群體接收不同版本的模型，透過商業指標（點擊率、轉換率、用戶滿意度）決定最終採用哪個版本。
三、關鍵優勢
持續部署帶來的主要優勢有三個層次。第一是速度：從程式碼提交到使用者看到新功能，可以從原本的數週壓縮到數小時甚至數分鐘。第二是品質：因為每次變更都很小，出現問題時更容易定位根因；自動化測試覆蓋也逼使工程師維持高品質的測試套件。第三是風險降低：小批次頻繁發布比大版本低頻發布風險更低，因為單次變更影響面積小，且回滾成本低。
四、前提條件與挑戰
實施持續部署並非沒有門檻。組織需要具備足夠高的自動化測試覆蓋率，通常要求關鍵路徑的單元測試覆蓋率在 80% 以上；需要建立完善的可觀測性（Observability）基礎設施，包括日誌、指標與分散式追蹤；同時組織文化也需要接受「每天部署數十次」的工作節奏。
對於 AI 系統，還需面對資料漂移（Data Drift）與模型退化（Model Degradation）的監控問題，因為即使程式碼未變，生產環境中的輸入資料分佈改變也可能導致模型表現下滑。
五、與 iPAS 考試的關聯
在 iPAS AI 應用規劃師考試中，持續部署通常出現在 MLOps 流程設計與 AI 系統維運的情境題中。考生需要理解 CI/CD/CT（持續訓練）三者之間的差異，以及在模型上線後如何設計監控與回滾機制，這是中級考試中架構設計能力的重要評量點。