從0到1瞭解CI/CD：初學者入門必備

本文先介紹了系統構建的先決技術與實踐，自動化構建、版本控制，並給出了Java環境下一些構建工具，而後分別介紹了持續集成（CI）、持續交付和持續部署（CD）的概念及其優點，並在最後給出了一些最佳實踐，如確保部署一致、保證良好的測試覆蓋率等。

---

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

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

本文將介紹什麼是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的出現大大提升了開發團隊的生產效率，縮短了開發週期。其敏捷、穩定、可靠的特性，也愈來愈被企業所青睞與須要。本文先介紹了系統構建的先決技術與實踐，自動化構建、版本控制，並給出了Java環境下一些構建工具，而後分別介紹了持續集成（CI）、持續交付和持續部署（CD）的概念及其優點，並在最後給出了一些最佳實踐，如確保部署一致、保證良好的測試覆蓋率等。但願能幫助你們釐清CI/CD的特性及功能，同時也但願CI/CD的初學者能藉由本文得以入門。