CI/CD是實現敏捷和Devops理念的一種方法，具體而言，CI/CD 可讓持續自動化和持續監控貫穿於應用的
整個生命週期（從整合和測試階段，到交付和部署）。這些關聯的事務通常被統稱為“CI/CD 管道”，由開發、
測試、運維團隊以敏捷方式協同支援。
首先是瀑布，其次是敏捷，現在是DevOps。這就是現代開發人員開發優質產品的方式。隨著DevOps的興
起，出現了持續整合，持續交付（CI / CD）和持續部署的新方法。傳統的軟體開發和交付方法正在迅速過時。
從歷史上看，在敏捷時代，大多數公司會以每月，每季度，每半年甚至每年的發行版來部署/銷售軟體（還記得
那些日子嗎？）。但是，現在在DevOps時代，每週，每天甚至一天多次都是標準。當SaaS接管世界時，尤其
如此，您可以在不強迫客戶下載新元件的情況下，輕鬆地動態更新應用程式。很多時候，他們甚至都不會意識
到事情正在發生變化。
持續整合（Continuous Integration）
大師 Martin Fowler 對持續整合是這樣定義的：持續整合是一種軟體開發實踐，即團隊開發成員經常整合他們的工作，
通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建（包括編譯，釋出，
自動化測試)來驗證，從而儘快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發
內聚的軟體。
持續整合的重點是將各個開發人員的工作產品融合到一個儲存庫中。通常，此操作每天要進行多次，其主
要目的是為了及早發現整合錯誤，最終將導致更緊密的內聚和更多的開發協作。連續輸送的目的是使展開或釋
放過程中固有的摩擦點最小化。通常，實現涉及自動化構建部署的每個步驟，以便可以隨時隨地（理想情況下）
完成安全的程式碼釋出。 連續部署是一種更高的自動化程度，其中，只要對程式碼進行了重大更改，都會自動進行
構建/部署。
通過持續整合，開發人員經常將其程式碼整合到通用儲存庫的主分支中。開發人員不會在每個週期的末尾單
獨構建功能並提交每個功能，而是會努力在任何一天多次向儲存庫貢獻軟體工作產品。
這裡的主要想法是通過讓開發人員更快，更頻繁地進行整合來降低整合成本。在實踐中，開發人員通常會
在整合時發現新程式碼與現有程式碼之間的邊界衝突。如果儘早且經常進行，則期望這樣的衝突解決方案將更容易
執行且成本更低。
當然，需要權衡取捨。此過程更改不提供任何其他質量保證。許多組織發現這種整合變得更加昂貴，因為
它們依靠手動過程來確保新程式碼不會引入新的錯誤，也不會破壞現有的程式碼。為了減少整合任務中的摩擦，連
續整合依賴於測試套件和自動測試執行。
持續交付（Continuous Delivery）
這裡借用阮一峰老師的說法，持續交付（Continuous delivery）指的是，頻繁地將軟體的新版本，交付
給質量團隊或者使用者，以供評審。如果評審通過，程式碼就進入生產階段。 持續交付可以看作持續整合的下一步。
它強調的是，不管怎麼更新，軟體是隨時隨地可以交付的。注意，持續交付在自動化測試和整合結束後，不一
定會自動部署。如果有自動部署，則是持續部署的概念了。
持續交付在持續整合的基礎上，將整合後的程式碼部署到更貼近真實執行環境的「類生產環境」
（production-like environments）中。比如，我們完成單元測試後，可以把程式碼部署到連線資料庫
的 Staging 環境中更多的測試。如果程式碼沒有問題，可以繼續手動部署到生產環境中。
持續部署（Continuous Deployment）
持續部署是指當交付的程式碼通過評審之後，自動部署到生產環境中。持續部署是持續交付的最高階
段。這意味著，所有通過了一系列的自動化測試的改動都將自動部署到生產環境。它也可以被稱為“Continuous Release”。
持續部署擴充套件了持續交付，因此，如果軟體構建通過所有測試，則將自動部署。在這樣的過程中，
不需要人來決定何時以及什麼生產。CI/CD系統的最後一步將自動部署成功退出交付管道的所有構建組
件/軟體包。可以將此類自動部署配置為快速向客戶分發元件，功能和修補程式，並準確地提供當前生
產中的內容。
結語
持續整合、持續交付、持續部署相輔相成，提供了一個良好的DevOps環境，對於整個團隊來說，
收益與挑戰並行。從軟體開發發展的趨勢來看，頻繁部署、快速交付以及開發測試流程的自動化將成
為未來軟體工程的重要組成部分。