共計 3701 個字符，預計需要花費 10 分鐘才能閱讀完成。

丸趣 TV 小編今天帶大家了解怎么了解 CI/CD，文中知識點介紹的非常詳細。覺得有幫助的朋友可以跟著丸趣 TV 小編一起瀏覽文章的內容，希望能夠幫助更多想解決這個問題的朋友找到問題的答案，下面跟著丸趣 TV 小編一起深入學習“怎么了解 CI/CD”的知識吧。

現代軟件開發的需求加上部署到不同基礎設施的復雜性使得創建應用程序成為一個繁瑣的過程。當應用程序出現規模性增長，開發團隊人員變得更分散時，快速且不斷地生產和發布軟件的流程將會變得更加困難。

為了解決這些問題，開發團隊開始探索新的策略來使他們的構建、測試和發布流程自動化，以幫助其更快地部署新的生產。這就是持續交付和持續集成發展的由來。

丸趣 TV 小編將介紹什么是 CI/CD 并且它是如何幫助團隊迅速開發部署經過充分測試、可靠的軟件。在了解 CI/CD 及其優勢之前，我們應該討論這些系統構建的一些先決技術和實踐。

自動構建流程

在軟件開發過程中，構建流程會將開發人員生成的代碼轉換為可執行的可用軟件。對于 Go 或者 C 語言等編譯語言，此階段需要通過編譯器運行源代碼以生成獨立的二進制文件。對于 Python 或 PHP 等解釋性語言，沒有編譯的步驟，但是代碼依舊需要在特定的時間內凍結、綁定依賴項、打包以便于分發。這些過程通常稱為“構建”或“發布”的工件。

雖然開發人員可以手動構建，但這樣操作有諸多不利。首先，從主動開發到創建構建的轉變中引入了上下文轉換，使得開發人員不得不停止生產效率更高的工作來專注于構建過程。其次，每個開發人員都在制作自己的工件，這可能導致構建過程不一致。

為了解決這些顧慮，許多開發團隊配置了自動構建流水線。這些系統監視源代碼存儲庫，并在檢測到更改時自動啟動預配置的構建過程。這一配置無需牽涉過多的人力在其中并且確保了每個構建過程一致。

市場上有許多幫助用戶自動化這些步驟的構建工具，以下列出了在 Java 生態下比較受歡迎的構建工具：

Ant：Apache Ant 是一個開源 Java 庫，創建于 2000 年。它是 Java 領域的原始構建工具，至今仍然被頻繁使用。

Maven：Apache Maven 是一個自動化構建工具，主要是為 Java 項目編寫的。不同于 Apache Ant，Maven 遵循約定優于配置的原則，僅需要針對偏離合理默認值的構建過程的方面進行配置。

Gradle：在 2012 年推出的 1.0 版本中，Gradle 嘗試通過結合 Maven 的現代功能來融合 Ant 和 Maven 的優勢，同時又不失 Ant 提供的靈活性。構建指令是用一種名為 Groovy 的動態語言編寫的。盡管在這個領域，這是一個相對比較新的工具，但它已被廣泛采用。

版本控制

大部分現代軟件開發需要在共享的代碼庫中進行頻繁協作。版本控制系統（VCS）用于幫助維護項目歷史記錄，并行處理離散特征，以及解決存在沖突的更改。VCS 允許項目輕松采用更改并在出現問題時回滾。開發人員可以在本地計算機上處理項目，并使用 VCS 來管理不同的開發分支。

記錄在 VCS 中的每個更改都稱為提交。每個提交都對代碼庫的更改進行編目分類，元數據也包含在其中，例如關于查看提交歷史記錄或合并更新的描述。

圖 1 分布式版本控制

雖然版本控制是一個十分有價值的工具，它能幫助管理在單一代碼庫中許多不同的更改。但分布式開發通常會為其帶來挑戰。在沒有定期合并到共享集成分支的情況下在代碼庫的獨立分支中進行開發可能會使以后合并更改變得困難。為了避免這一情況，開發人員開始采納持續集成實踐。

持續集成（CI）

持續集成（CI）是一個讓開發人員將工作集成到共享分支中的過程，從而增強了協作開發。頻繁的集成有助于解決隔離，減少每次提交的大小，以降低合并沖突的可能性。

為了鼓勵 CI 實踐，一個強大的工具生態已經構建起來。這些系統集成了 VCS 庫，當檢測到更改時，可以自動運行構建腳本并且測試套件。集成測試確保不同組件功能可以在一個組內兼容，使得團隊可以盡早發現兼容性的 bug。因此，持續集成所生產的構建是經過充分測試的，并且是完全可靠的。

圖 2 持續集成的過程

持續交付和持續部署（CD）

持續交付和持續部署是在構建持續集成的基礎之上的兩種策略。持續交付是持續集成的擴展，它將構建從集成測試套件部署到預生產環境。這使得它可以直接在類生產環境中評估每個構建，因此開發人員可以在無需增加任何工作量的情況下，驗證 bug 修復或者測試新特性。一旦部署到 staging 環境中，就可能需要進行額外的手動和自動測試。

持續部署則更進一步。一旦構建在 staging 環境中通過了自動測試，持續部署系統將會自動將它部署到生產服務器上。換言之，每個通過測試的構建都是實時的，可供用戶及早反饋。這使得團隊可以不斷發布新特性和修復 bug，并以其測試流程提供的保證為后盾。

圖 3 CI / CD 流程路線圖

CI/CD 的優勢

持續集成、交付和部署對軟件開發過程有顯著的改進。下文將簡單介紹一些 CI/CD 的主要優勢：

快速反饋回路

對于一個快速的開發周期，快速反饋回路顯得尤為重要。為了能夠實時接收反饋，軟件必須迅速觸達終端用戶。而 CI / CD 可以通過簡化更新生產部署來提供實現此目標的平臺。通過要求每個更改都經過嚴格的測試，CI 可以幫助降低每個構建的相關風險并因此使得團隊可以便捷地向用戶發布有價值的特性。

增加可見度

CI/CD 通常是指將 IT 流程的各個步驟按序列組成一條流水線，且該流水線對整個 IT 團隊（包括開發、測試、運維等團隊）均可見。因此，每個團隊成員可以跟蹤系統中的構建狀態并且可以確定任何導致測試失敗的構建。團隊成員通過深入了解代碼庫的當前狀態，可以更輕松地規劃最佳行動方案。這樣的可見度為這一問題提供了一個明確的答案——“我提交的更改是否破壞了構建？”

簡化故障排除

盡管 CI 的目標是集成并測試每個發生在代碼庫中的更改，但是更安全的方式是每次提交都是小型的并盡早將它們合并到共享代碼存儲庫中。如此，當找到 bug 時，確定和問題相關的更改會更加容易。畢竟，根據問題的嚴重程度，團隊可以選擇回滾或編寫并提交修復，從而減少生產中解決問題的時間。

軟件質量更高

自動化構建和部署流程不僅縮短了開發周期，而且幫助團隊開發出品質更好的軟件。因為每個更改都會經過充分的測試并且至少會部署在一個預生產環境中，因此團隊可以毫無顧慮地將更改部署到生產中。不過，只有當代碼庫的所有級別，從單元測試到更復雜的系統測試，都有良好的測試覆蓋率時，才能實現這一點。

集成問題更少

因為自動化測試套件在每次提交時自動生成的構建上運行，所以可以盡早檢測并修復集成問題。這使開發人員能夠及早了解當前正在進行的工作是否可能影響其代碼。它會在一開始就測試由不同貢獻者編寫的代碼是否兼容，而不是在之后可能出現其他問題的時候才開始測試。

有更多的時間專注于開發

CI/CD 系統依賴自動化來生產構建并且通過流水線來遷移新的更改。由于不需要手動干預，因此構建和測試不再占用開發團隊大塊的時間。進而開發人員可以心無旁騖地對代碼庫進行有效的更改，因為如果構建過程中出現任何問題，自動化系統會通知他們。

持續集成和交付的最佳實踐

既然我們已經了解了使用 CI/CD 的一些優勢，那么接下來，我們將討論一些指導原則來幫助您成功實現這些流程。

對 CI / CD 流水線負責

開發者直到更改被部署到預生產環境中，才無需對其提交的代碼負責。這意味著開發者必須確保他們的代碼集成正確并且隨時可以部署。如果提交的更改違反了這些要求，則開發人員有責任快速提交修復以避免影響其他人的工作。構建失敗應該暫停流水線并阻止不參與修復故障的提交，這使得快速解決構建問題變得至關重要。

確保部署一致

部署過程不需要手動操作，反而流水線需要自動部署流程以確保一致性和可重復性。這減少了將破壞性構建推向生產的可能性，并有助于避免出現一些難以重現的、未經測試的配置。

將代碼庫提交到版本控制

將每次更改提交到版本控制是十分重要的。這會幫助團隊審核所有提交的變更并且讓團隊可以簡單地還原出現問題的提交。同時，也可以保持配置、腳本、數據庫和文檔的完整性。如果沒有版本控制，特別是當多人使用同一個代碼庫時，會非常容易丟失配置和代碼更改或對其處理不當。

提交小的、漸進的更改

開發人員一定要牢記：更改必須是小的。因為等待引入更大批量的更改會延遲測試反饋，會更難以確定問題的根本原因。

良好的測試覆蓋率

由于 CI / CD 的目的是減少手動測試，因此整個代碼庫應該有一個良好的自動化測試覆蓋率，以確保軟件按預期運行。此外，還應該定期清理冗余或過時的測試以避免影響流水線。

測試套件中不同類型測試的比例應和“測試金字塔”模型相似。大多數測試應該是單元測試，因為它們擁有基本功能的同時還可以快速執行。此外，還要有較少數量的集成測試，以確保組件可以一起成功運行。最后，應在測試周期結束時包含少量回歸、UI、系統和端到端測試，以確保構建滿足項目的所有行為要求。可以使用像 JaCoCo 這樣的工具來確定測試套件涵蓋了多少代碼庫。

圖 4 測試金字塔

感謝大家的閱讀，以上就是“怎么了解 CI/CD”的全部內容了，學會的朋友趕緊操作起來吧。相信丸趣 TV 丸趣 TV 小編一定會給大家帶來更優質的文章。謝謝大家對丸趣 TV 網站的支持！