淺談持續集成(CI)、持續交付(CD)、持續部署(CD)
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環境，對於整個團隊來說，
收益與挑戰並行。從軟件開發發展的趨勢來看，頻繁部署、快速交付以及開發測試流程的自動化將成
為未來軟件工程的重要組成部分。
