持續交付（Continuous Delivery，簡稱 CD）
持續交付（CD）是一種軟體工程方法，旨在通過自動化的軟體交付過程，快速且可靠地將軟體更改部署到生產環境。這種方法強調了開發、測試和發布軟體的自動化和持續性，使得軟體交付變得更加迭代和頻繁。
在CD流程中，開發團隊會頻繁地提交代碼更改到共享repo，這些更改會自動進行構建、測試和準備部署。這種方法的核心在於減少軟體交付的時間和風險，同時提高產品品質和客戶滿意度。CD允許開發團隊快速回應市場變化和客戶需求，並支持更加敏捷的迭代。
持續交付與持續集成（CI）緊密相關，通常與CI一起實施，形成CI/CD管道。這種結合實踐確保了軟體開發的整個過程從程式碼提交到產品交付都是自動化和持續的，從而實現更快速、更可靠的軟體發布。
部署策略比較
滾動策略部署（Rolling Deployment）
流程
- 逐步更新：將新版本逐步部署到生產環境的一部分伺服器上。
- 監控與測試：在每次更新後進行監控和測試。
- 逐步擴展：如果一切正常，繼續將更新推送到更多伺服器。
定義與特點
滾動策略部署是 Kubernetes 中最常用的部署方式。它逐步替換舊版本的Pods，每次只更新一部分，直至全部替換為新版本。這種策略的主要特點是無需停機，可以實現無縫更新。
優點
- 最小化停機時間：由於新舊版本 Pods 同時運行，因此確保了服務的持續可用性。
- 風險控制：如果新版本出現問題，可以立即停止部署，減少對整體系統的影響。
- 資源利用最佳化：新舊版本共存，不需要額外的運行環境。
缺點
- 版本兼容性要求：新舊版本需要能夠同時運行，對版本間的兼容性有較高要求。
- 更新速度較慢：由於是逐步更新，因此整體部署速度不如一些其他策略快。
藍/綠部署（Blue/Green Deployment）
流程
- 準備兩個相同的環境：藍色（當前運行版本）和綠色（新版本）。
- 部署新版本到綠色環境：在綠色環境中部署並測試新版本。
- 切換流量：一旦新版本準備就緒，將用戶流量從藍色環境切換到綠色環境。
- 回滾計劃：如果新版本出現問題，可以迅速切回藍色環境。
定義與特點
藍/綠部署同時運行兩個完全相同的環境：一個運行舊版本（藍色），另一個運行新版本（綠色）。一旦新版本準備就緒並通過測試，流量就會從藍色切換到綠色。
優點
- 快速回滾：如果新版本出現問題，可以迅速切回到舊版本。
- 測試容易：在正式切換前，可以在生產環境中徹底測試新版本。
- 立即更新：一旦切換，更新立即生效。
缺點
- 資源需求高：需要維護兩套完全相同的環境，對資源的需求較高。
- 切換風險：雖然可以迅速回滾，但切換過程中可能會出現短暫的不可用。
金絲雀部署（Canary Deployment）
流程
- 小範圍部署：首先將新版本部署到一小部分用戶（金絲雀群體）。
- 監控反饋：密切監控性能和用戶反饋。
- 全面推廣：如果反饋正面，則逐步將新版本推廣到所有用戶。
定義與特點
金絲雀部署是一種逐步推出新版本的策略，先在少數用戶中測試新版本，然後根據反饋逐步擴大範圍。這種策略允許開發者收集有關新版本性能和穩定性的實時數據。
優點
- 風險最小化：只對一小部分用戶推出新版本，如果出現問題，影響範圍有限。
- 實時反饋：可以根據實際用戶的使用情況來調整和優化新版本。
- 靈活性高：根據需要可以隨時調整推出新版本的範圍。
缺點
- 複雜性高：需要精確控制哪些用戶獲得新版本，這可能增加部署的複雜性。
- 時間較長：相比其他策略，金絲雀部署可能需要更長的時間來完全推出新版本。
重新創建部署（Recreate Deployment）
流程
- 停止舊版本：首先完全停止運行中的舊版本應用。
- 部署新版本：一旦舊版本停止，立即部署新版本的應用。
- 啟動新版本：新版本部署完成後，啟動新版本的應用。
定義與特點
重新創建部署是一種簡單直接的更新策略，它會同時停止所有舊版本的 Pods ，然後創建新版本的 Pods。
優點
- 簡單明了：這種策略操作簡單，易於理解和實施。
- 清晰的版本切換：一次性完成所有舊版本的下線和新版本的上線，避免了版本混淆的問題。
- 適合不需要持續運行的應用：對於不需要24小時運行的應用，這種策略非常合適。
缺點
- 停機時間：在舊版本下線和新版本上線的過程中，應用會暫時不可用。
- 風險較高：如果新版本有問題，需要重新進行整個部署過程，風險和成本較高。
- 不適合高可用系統：對於需要高可用性的系統，這種策略可能不是最佳選擇。
A/B 部署（A/B Deployment）
流程
- 分組測試：將用戶隨機分為兩組，一組使用新版本，另一組使用舊版本。
- 收集數據：分析兩組用戶的行為和反饋。
- 決策部署：根據數據決定是否全面推廣新版本。
定義與特點
或 A/B 測試是將新功能僅釋放給一部分用戶的策略。這種策略通常用於前端功能的測試，可以基於用戶特徵或行為來決定誰可以看到新功能。
優點
- 精準的用戶目標：可以根據用戶群體的特定特徵來進行功能測試。
- 即時反饋：可以從特定用戶群體獲得關於新功能的即時反饋。
- 減少風險：由於只有一部分用戶看到新功能，因此即使新功能有問題，也不會影響所有用戶。
缺點
- 實施複雜：需要複雜的用戶分群和路由邏輯來確保正確的用戶群體看到新功能。
- 數據分析挑戰：分析不同用戶群體的反饋可能比較複雜，需要精確的數據收集和分析。
- 可能影響用戶體驗：不同用戶看到不同版本的應用可能會導致用戶體驗的不一致性。
部屬工具比較
1. Jenkins
- 特點：Jenkins是一個開源的自動化工具，廣泛用於持續集成和持續交付。它支持各種插件，可用於自動化各種開發、部署和測試任務。
- 優勢：高度可定制和靈活，擁有大量的社區支持和插件。
- 適用場景：適合需要高度定制化CI/CD流程的團隊。
2. GitLab CI/CD
- 特點： GitLab CI/CD 是一個集成在 GitLab 中的 CI/CD 工具，提供了從代碼提交到自動部署的完整流程。
- 優勢：緊密集成於 GitLab 生態系統，易於使用，並提供了一個統一的界面來管理整個 CI/CD 流程。
- 適用場景：適合已經使用 GitLab 作為代碼儲存庫的團隊。
3. CircleCI
- 特點： CircleCI 是一個雲端和自託管的 CI/CD 服務，支持快速的構建、測試和部署。
- 優勢：易於設置和使用，提供了強大的集成選項，並支持多種編程語言和框架。
- 適用場景：適合尋求快速、可靠且易於設置的 CI/CD 解決方案的團隊。
4. Travis CI
- 特點： Travis CI 是一個流行的 CI/CD 服務，專為 GitHub 項目設計，支持多種語言。
- 優勢：簡單易用，與 GitHub 緊密集成，支持自動化構建和測試。
- 適用場景：適合使用 GitHub 並尋求簡單 CI/CD 設置的小型至中型項目。
5. Ansible
- 特點： Ansible 是一個開源的自動化平台，用於配置管理、應用部署等。
- 優勢：無需代理，使用 SSH 進行通訊，易於編寫的 YAML 腳本。
- 適用場景：適合需要自動化配置管理和應用部署的複雜環境。
6. GitHub Actions
- 特點： GitHub Actions 是 GitHub 的自動化和 CI/CD 平台，允許用戶在 GitHub 倉庫中直接創建、測試和部署代碼。
- 優勢：與 GitHub 緊密集成，無需額外的 CI/CD 工具或服務。支持廣泛的語言和平台，並且可以通過市場上的現成 Actions 輕鬆擴展功能。
- 適用場景：特別適合那些已經使用 GitHub 作為代碼存儲和版本控制系統的團隊，希望在同一平台上管理他們的 CI/CD 流程。
7. Azure devops
- 特點：Azure DevOps 是微軟提供的一套完整的開發、部署和協作工具集。它包括了 Azure Repos、Azure Boards、Azure Pipelines、Azure Test Plans 和 Azure Artifacts。
- 優勢：全面的解決方案：提供從代碼儲存、項目管理到 CI/CD 的一站式服務。
- 緊密集成：與微軟的其他產品和服務（如 Azure、Office 365）有良好的集成。
- 靈活性和擴展性：支持各種語言和平台，並且可以通過市場上的插件進行擴展。
- 適用場景：適合那些尋求集成化解決方案的企業，特別是已經在使用微軟生態系統的組織。
