怎么了解CI/CD

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

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

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

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

自動構建流程

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

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

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

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

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

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

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

版本控制

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

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

圖1 分布式版本控制

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

持續(xù)集成（CI）

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

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

圖2 持續(xù)集成的過程

持續(xù)交付和持續(xù)部署（CD）

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

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

圖3 CI / CD流程路線圖

CI/CD的優(yōu)勢

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

快速反饋回路

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

增加可見度

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

簡化故障排除

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

軟件質(zhì)量更高

自動化構建和部署流程不僅縮短了開發(fā)周期，而且?guī)椭鷪F隊開發(fā)出品質(zhì)更好的軟件。因為每個更改都會經(jīng)過充分的測試并且至少會部署在一個預生產(chǎn)環(huán)境中，因此團隊可以毫無顧慮地將更改部署到生產(chǎn)中。不過，只有當代碼庫的所有級別，從單元測試到更復雜的系統(tǒng)測試，都有良好的測試覆蓋率時，才能實現(xiàn)這一點。

集成問題更少

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

有更多的時間專注于開發(fā)

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

持續(xù)集成和交付的最佳實踐

既然我們已經(jīng)了解了使用CI/CD的一些優(yōu)勢，那么接下來，我們將討論一些指導原則來幫助您成功實現(xiàn)這些流程。

對CI / CD流水線負責

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

確保部署一致

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

將代碼庫提交到版本控制

將每次更改提交到版本控制是十分重要的。這會幫助團隊審核所有提交的變更并且讓團隊可以簡單地還原出現(xiàn)問題的提交。同時，也可以保持配置、腳本、數(shù)據(jù)庫和文檔的完整性。如果沒有版本控制，特別是當多人使用同一個代碼庫時，會非常容易丟失配置和代碼更改或?qū)ζ涮幚聿划敗?/p>

提交小的、漸進的更改

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

良好的測試覆蓋率

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

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

圖4 測試金字塔

感謝大家的閱讀，以上就是“怎么了解CI/CD”的全部內(nèi)容了，學會的朋友趕緊操作起來吧。相信億速云小編一定會給大家?guī)砀鼉?yōu)質(zhì)的文章。謝謝大家對億速云網(wǎng)站的支持！