本篇重點
- 定義 DevOps、CI 與 CD 核心概念
- 解析 CI 與 CD 的差異
- 解析 CI/CD 流水線標準流程及應用場景
- 說明 CI 與 CD 的異常處理
- 說明 DevOps 與 CI/CD 的關係
DevOps 開發與營運
Development & Operations
一種強調開發（Development）與營運（Operations）團隊協作的概念，並非單一的工具或是職位。
核心概念
- 跨團隊協作（開發 + 營運）
- 自動化流程（建置、測試、部署）
- 提高部署頻率
- 確保系統穩定性
- 即時監控
範例
傳統流程：開發完成 → 手動交給營運部署 → 問題回報慢
DevOps：開發提交程式碼 → 自動測試 → 自動部署 → 即時監控
CI 持續整合
Continuous Integration
開發人員將程式碼整合到主分支，系統會自動啟動建置與測試，確保新程式碼不會破壞既有功能，提高穩定性。
核心目標
- 保持主分支穩定
- 提早發現錯誤
- 降低整合風險
範例
每次 push / pull request 都會觸發流程，自動執行：
- Build（編譯 / 打包）
- Test（單元測試）
CD 持續交付 / 部署
Continuous Delivery / Deployment
CD 分為兩種模式：
- **持續交付 (Continuous Delivery)**：程式碼通過測試後，自動進入可發布狀態，但部署至正式環境需要手動觸發。
- **持續部署 (Continuous Deployment)**：通過所有測試的程式碼會自動部署到生產環境，完全不需人工介入。
範例
CI 測試通過後：
- Continuous Delivery 觸發 deploy job，但需手動批准
- Continuous Deployment 自動部署到 production
CI 與 CD 的差異
總結持續整合、持續交付與持續部署在操作層級的差異：
| 階段特性 | 持續整合 (CI) | 持續交付 (CD) | 持續部署 (CD) |
|---|---|---|---|
| 主要目的 | 驗證程式碼正確性 | 確保隨時可發布 | 自動化上線流程 |
| 觸發方式 | 代碼推送 (Push) | 代碼合併 (Merge) | 通過測試後自動執行 |
| 人工介入 | 無 | 需要 (最終部署) | 無 |
CI/CD Pipeline
標準流程
標準的 Pipeline 包含一系列自動化步驟，確保程式碼從提交到上線的品質。
- **原始碼階段 (Source)**：開發者將程式碼提交至 Git 倉庫，觸發 Pipeline。
- **建置階段 (Build)**：編譯程式碼、下載依賴套件，並將其打包成 Docker 鏡像或執行檔。
- **測試階段 (Test)**：執行單元測試 (Unit Test)、整合測試 (Integration Test) 與代碼掃描 (Linting)。
- **部署階段 (Deploy)**：將產出物發布至測試、預發布或正式環境。
應用場景
- 全端專案交付
整合前後端的自動化流程。當開發者提交程式碼時，系統會自動執行 API 整合測試與前端資源打包（Build），並將結果部署至測試環境或 CDN，確保在正式上線前完成嚴謹的驗證與檢查。 - 微服務架構管理
針對解耦的大型系統，為數十甚至數百個微服務建立「各自獨立」的 CI/CD Pipeline。這讓團隊能針對單一模組進行快速更新或錯誤回滾，避免一次更新全部的功能，大幅提升系統的擴充性與容錯能力。 - 多人協作與持續整合
開發階段的品質把關和分支管理。在多人團隊同時開發不同功能時，CI/CD 會即時偵測分支合併可能產生的衝突與邏輯錯誤，確保主分支（Main Branch）的程式碼永遠維持在「隨時可部署」的高品質狀態。 - 高頻發布需求
為需要快速反應市場的電商或社交平台設計。CI/CD 能將傳統冗長、需要人工介入的發布流程壓縮，讓團隊具備每日多次穩定上線的能力，快速推出新功能或修復緊急 Bug。
健忘筆記
「解耦」（Decoupling） 是一個技術概念，將原本緊密連結、互相牽制的系統，拆解成多個「獨立且不依賴」的小單元，解耦後的營運優勢有 1.各自獨立的 CI/CD Pipeline 2.單一模組可以快速更新或是回滾 3.提升擴充性
CI/CD 異常處理
在 Pipeline 執行過程中，錯誤發生後的「中止與否」取決於觸發事件（push 或 PR）以及 pipeline 設計，但多數情況會停止後續步驟並回報狀態。
不同情境下流程失敗的處理邏輯：
| 項目 | 直接 Push | Pull Request |
|---|---|---|
| 流程是否終止 | 是，後續階段中斷 | 是，禁止合併 |
| 對分支的影響 | 分支狀態顯示為 Fail | 目標分支受保護，不受影響 |
| 恢復手段 | 提交新 Commit 修復或 Revert | 修正程式碼重新提交 |
- CI/CD 不會阻止 commit 寫入 Git，因為 push 已完成，CI 僅影響「狀態」，不影響 Git 結構
- CI/CD 主要作用在「驗證與阻擋後續流程（如 deploy / merge）」
- PR 流程可有效避免錯誤進入主分支
- push 進主分支需搭配保護機制，否則可能引入不穩定版本
在有 CI/CD 架構的專案中，建議使用 PR（Pull Request）做更新，而不是直接 Push 到主分支，確保錯誤的內容影響 git 分支、影響生產環境。
健忘筆記
在 github 中可以設定 repositery 開啟分支保護和禁止 Force Push 的相關設定，達到防呆的效果。
DevOps 與 CI/CD 的關係
DevOps 是開發與營運的整體概念，而 CI/CD 是實現 DevOps 的實作技術。
- DevOps 提供目標：例如提升交付速度、強化系統穩定性等。
- CI/CD 提供工具：透過自動化工具鏈（如 GitHub Actions, Jenkins, GitLab CI）執行重複性任務，達到自動化流程、減少人為操作等效果。
結論
CI/CD 是現代軟體開發的核心基礎設施，透過 CI 的持續整合與 CD 的持續交付或部署落實 DevOps 的概念。藉由嚴謹的 Pipeline 監控與異常阻斷機制，開發團隊能在追求交付速度的同時，強化系統穩定性與品質控管。
