持續整合與交付部署（CI/CD）

 CI / CD的採用改變了開發人員和測試人員如何發佈軟體。

最初是瀑布模型，後來是敏捷開發，現在是DevOps，這是現代開發人員構建出色的產品的技術路線。隨著DevOps的興起，出現了持續整合（Continuous Integration）、持續交付（Continuous Delivery） 、持續部署（Continuous Deployment） 的新方法。傳統的軟體發展和交付方法正在迅速變得過時。從歷史上看，在敏捷時代，大多數公司會每月，每季度，每兩年甚至每年發佈部署/發佈軟體。然而，現在，在DevOps時代，每週，每天，甚至每天多次是常態。當SaaS正在佔領世界時，尤其如此，您可以輕鬆地動態更新應用程式，而無需強迫客戶下載新元件。

持續整合（CI）的重點是將各個開發人員的工作集合到一個代碼倉庫中。通常，每天都要進行幾次，主要目的是儘早發現集成錯誤，使團隊更加緊密結合，更好地協作。
持續交付（CD）的目的是最小化部署或釋放過程中固有的摩擦。它的實現通常能夠將構建部署的每個步驟自動化，以便任何時刻能夠安全地完成代碼發佈（理想情況下）。
持續部署（CD）是一種更高程度的自動化，無論何時對代碼進行重大更改，都會自動進行構建/部署。這些階段中的每一個都是交付管道的一部分 。

 一、持續整合（CI）

通過持續整合，開發人員能夠頻繁將其代碼集成到公共代碼倉庫的主分支中。開開發人員能夠在任何時候多次向倉庫提交作品，而不是獨立地開發每個功能模組並在開發週期結束時一一提交。
這裡的一個重要想法是讓開發人員更快，更頻繁地做到這一點，從而降低集成成本。實際情況中，開發人員在集成時經常會發現新代碼和已有代碼存在衝突。如果集成較早並更加頻繁，那麼衝突將更容易解決且執行成本更低。當然，還有一些權衡。此流程變更不提供任何額外的品質保證。實際上，許多組織發現這種集成變得更加昂貴，因為它們依賴於手動過程來確保新代碼不會引入新的錯誤，並且不會破壞現有代碼。為了減少集成任務期間的摩擦，持續整合依賴於測試套件和自動化測試執行。然而，要認識到自動化測試和持續測試是完全不同的這一點很重要，我們會在文章結尾處詳細說明。
CI 的目標是將集成簡化成一個簡單、易於重複的日常開發任務，這將有助於降低總體構建成本，並在週期的早期發現缺陷。要想有效地使用 CI 必須轉變開發團隊的習慣，要鼓勵頻繁反覆運算構建，並且在發現 bug 的早期積極解決。

二、持續交付（CD）

實際上是 CI 的擴展，其中軟體交付流程進一步自動化，以便隨時輕鬆地部署到生成環境中。CD 集中依賴於部署流水線，團隊通過流水線自動化測試和部署過程。此流水線是一個自動化系統，可以針對構建執行一組漸進的測試套件。CD 具有高度的自動化，並且在一些雲計算環境中也易於配置。在流水線的每個階段，如果構建無法通過關鍵測試會向團隊發出警報。否則，將繼續進入下一個測試，並在連續通過測試後自動進入下一個階段。流水線的最後一個部分會將構建部署到和生產環境等效的環境中。這是一個整體的過程，因為構建、部署和環境都是一起執行和測試的，它能讓構建在實際的生產環境可部署和可驗證。持續交付的吸引力主要在於，它自動化了從提交代碼到倉庫，再到測試和發佈產品過程的所有步驟。這是構建和測試過程細緻的自動化，但是如何發佈以及發佈什麼仍然是需要人工作業，持續部署可以改變這一點。

三、持續部署（CD）

持續部署擴展了持續交付，以便軟體構建，在通過所有測試時自動部署。在這樣的流程中，不需要人為決定何時及如何投入生產環境。CI/CD 系統的最後一步將在構建後的組件/包退出流水線時自動部署。此類自動部署可以配置為快速向客戶分發元件、功能模組或修復補丁，並準確說明當前提供的內容。
採用持續部署的組織可以將新功能快速傳遞給用戶，得到用戶對於新版本的快速回饋，並且可以迅速處理任何明顯的缺陷。用戶對無用或者誤解需求的功能的快速回饋有助於團隊規劃投入，避免將精力集中於不容易產生回報的地方。隨著 DevOps 的發展，新的用來實現 CI/CD 流水線的自動化工具也在不斷湧現。這些工具通常能與各種開發工具配合，包括像 GitHub 這樣的代碼倉庫和 Jira 這樣的 bug 跟蹤工具。此外，隨著 SaaS 這種交付方式變得更受歡迎，許多工具都可以在現代開發人員運行應用程式的雲環境中運行，例如 GCP 和 AWS。最受歡迎的自動化工具是 Jenkins（以前的 Hudson），這是一個由數百名貢獻者和商業公司 Cloudbees 支持的開源專案。Cloudbees 甚至聘請了 Jenkins 的創始人，並提供了一些 Jenkins 培訓專案和附加元件。除了開源專案之外，還有一些更現代化的商業產品例如 CircleCI，Codeship 和 Shippable。這些產品各有優缺點，我鼓勵開發人員在開發流程中一一嘗試它們，以瞭解它們在您的環境中的工作方式，以及它們如何與您的工具、雲平臺、容器系統等協作。

四、解決方案（Jenkins）

Jenkins為以上的CI/CD提供可行的解決方案,詳情請看之後的文章。

 

持續整合、持續交付、持續部署（CI/CD）簡介

 

概述：

軟體開發週期中需要一些可以幫助開發者提升速度的自動化工具。其中工具最重要的目的是促進軟體專案的持續整合與交付。通過CI/CD工具，開發團隊可以保持軟體更新並將其迅速的投入實踐中。CI/CD也被認為是敏捷開發的最重要實踐之一。

一 、持續整合

從上圖可以看到，持續整合應該至少包括以下幾部分：

• 自動化構建Continuous Build
• 自動化測試Continuous Test
• 自動化整合Continuous Intergration

1. 自動化構建

包括以下過程：

• 將原始碼編譯成為二進位制碼
• 打包二進位制碼
• 執行自動化測試
• 生成文件
• 生成分發媒體（例如：Debian DEB、Red Hat RPM或者Windows MSI檔案）

所以，自動化構建，從功能角度分，最關鍵的是三部分：版本控制工具、構建工具、CI伺服器。而其中最核心的又是構建工具。其他開源的、與持續整合相關的工具也有很多，但大多數是輔助性的工具。

(1)版本控制工具

有時，版本控制又稱為配置管理（SCM），所以版本控制工具同時也是配置管理工具。在各類版本控制的開源軟體中，最著名的莫過於CVS、SVN（Subversion）、GIT三個了。
這三個工具各有千秋。其中，GIT支援離線工作，更適合開源軟體或者開發人員不能集中辦公情況下的版本管理工作。同時，SVN和GIT可以配合使用。

（2）構建工具

構建工具是持續整合的核心，它對原始碼進行自動化編譯、測試、程式碼檢查，以及打包程式、部署（釋出）到應用伺服器上。從配置管理工具上下載最新原始碼後，所有的後續工作幾乎都可以通過構建工具完成。
在java開發中，比較有名的構建工具就是Ant、Maven、Gradle。在PHP開發中，Phing（基於Ant）也比較有名。同樣的，Maven也可通過相關的PHP-Maven外掛完成對PHP開發構建的支援。

（3）CI伺服器

CI伺服器的主要作用就是提供一個平臺，用於整合版本控制和構建工作，並管理、控制自動化的持續整合。
開源軟體中，比較有名的CI伺服器包括Jenkins、CruiseControl、Continuum。而比較有名的商業化CI伺服器是TeamCity、Bamboo、Pulse等。

（4）其他工具

很多工具可以通過與構建工具、CI工具相結合（當然，其中有很多工具也可以單獨工作），來完成更多的自動測試、報告生成等工作。根據工具不同，其具體的結合方法也不同，但大體都是通過外掛形式進行結合的。例如：

• Maven中通過依賴和plugin方式引入第三方工具
• Jenkins主要通過各類外掛引入第三方工具

這些工具種類實在太多，可以根據實際工作需要進行選擇。

2.自動化測試

自動化測試是持續整合必不可少的一部分，基本上，沒有自動化測試的持續整合，都很難稱之為真正的持續整合。我們希望持續整合能夠儘早的暴露問題，但這遠非配置一個 Hudson/Jenkins伺服器那麼簡單，只有真正用心編寫了較為完整的測試用例，並一直維護它們，持續整合才能孜孜不倦地執行測試並第一時間報告問題。

測試自動化是使用特定的軟體（獨立於被測試的軟體）來控制測試的執行以及比較實際輸出與預期輸出。測試自動化可以將某些重複但必要的任務自動化，或者執行某些難以手動執行的額外測試。

自動化測試還包括單元測試、整合測試、系統測試、驗收測試、效能測試等，在不同的場景下，它們都能為軟體開發帶來極大的價值。

二、持續交付

持續交付（Continuous Delivery, CD）是一種軟體工程的手段，讓軟體在短週期內產出，確保軟體隨時可以被可靠地釋出。其目的在於更快、更頻繁地構建、測試以及釋出軟體。通過加強對生產環境的應用進行漸進式更新，這種手段可以降低交付變更的成本與風險。一個簡單直觀的與可重複的部署過程對於持續交付來說是很重要的。

三、持續部署

如圖所示，持續部署與持續交付之間的差異就是前者將部署自動化了。
在持續交付的實踐中，交付的目標是QA，但是實際上，軟體最終是要交付到客戶手上的。在SaaS領域裡，持續部署採用得比較廣泛，因為服務比較容易做到靜默升級。
採用持續部署的前提是自動化測試的覆蓋率足夠高。
採用持續部署的好處是能減少運維的工作量，縮短新特性從開發到實際交付的週期

四、CI/CD具體實現

常見CI/CD工具及其比較:

這裡的支援，意思應該是直接的支援，例如Jenkins，其實和git結合也很簡單，通過指令碼就可以實現。

五、持續整合工具集之 Jenkins簡介

Jenkins 是一個可擴充套件的持續整合引擎。

1.主要用於：

• 持續、自動地構建/測試軟體專案。
• 監控一些定時執行的任務。Jenkins擁有的特性包括：

2.Jenkins擁有的特性包括：

• 易於安裝-只要把jenkins.war部署到servlet容器，不需要資料庫支援。
• 易於配置-所有配置都是通過其提供的web介面實現。
• 整合RSS/E-mail通過RSS釋出構建結果或當構建完成時通過e-mail通知。
• 生成JUnit/TestNG測試報告
• 分散式構建支援Jenkins能夠讓多臺計算機一起構建/測試。
• 檔案識別:Jenkins能夠跟蹤哪次構建生成哪些jar，哪次構建使用哪個版本的jar等。
• 外掛支援:支援擴充套件外掛，你可以開發適合自己團隊使用的工具。

3.Jenkins的出現

目前持續整合(CI)已成為當前許多軟體開發團隊在整個軟體開發生命週期內側重於保證程式碼質量的常見做法。它是一種實踐，旨在緩和和穩固軟體的構建過程。並且能夠幫助您的開發團隊應對如下挑戰：

• 軟體構建自動化 ：配置完成後，CI系統會依照預先制定的時間表，或者針對某特定事件，對目標軟體進行構建。
• 構建可持續的自動化檢查 ：CI系統能持續地獲取新增或修改後簽入的原始碼，也就是說，當軟體開發團隊需要週期性的檢查新增或修改後的程式碼時，CI系統會不斷確認這些新程式碼是否破壞了原有軟體的成功構建。這減少了開發者們在檢查彼此相互依存的程式碼中變化情況需要花費的時間和精力。
• 構建可持續的自動化測試 ：構建檢查的擴充套件部分，構建後執行預先制定的一套測試規則，完成後觸發通知(Email,RSS等等)給相關的當事人。
• 生成後後續過程的自動化 :當自動化檢查和測試成功完成，軟體構建的週期中可能也需要一些額外的任務，諸如生成文件、打包軟體、部署構件到一個執行環境或者軟體倉庫。這樣，構件才能更迅速地提供給使用者使用。

部署一個CI系統需要的最低要求是，一個可獲取的原始碼的倉庫，一個包含構建指令碼的專案。

下圖概括了CI系統的基本結構：
4.使用Jenkins的一些理由：

該系統的各個組成部分是按如下順序來發揮作用的：

• 開發者檢入程式碼到原始碼倉庫。
• CI系統會為每一個專案建立了一個單獨的工作區。當預設或請求一次新的構建時，它將把原始碼倉庫的原始碼存放到對應的工作區。
• CI系統會在對應的工作區內執行構建過程。
• （配置如果存在）構建完成後，CI系統會在一個新的構件中執行定義的一套測試。完成後觸發通知(Email,RSS等等)給相關的當事人。
• （配置如果存在）如果構建成功，這個構件會被打包並轉移到一個部署目標(如應用伺服器)或儲存為軟體倉庫中的一個新版本。軟體倉庫可以是CI系統的一部分，也可以是一個外部的倉庫，諸如一個檔案伺服器或者像Java.NET、 SourceForge之類的網站。
• CI系統通常會根據請求發起相應的操作，諸如即時構建、生成報告，或者檢索一些構建好的構件。

Jenkins就是這麼一個CI系統。之前叫做Hudson。

• 是所有CI產品中在安裝和配置上最簡單
• 基於Web訪問，使用者介面非常友好、直觀和靈活，在許多情況下，還提供了AJAX的即時反饋。
• Jenkins是基於Java開發的(如果你是一個Java開發人員，這是非常有用的)，但它不僅限於構建基於Java的軟體。
• Jenkins擁有大量的外掛。這些外掛極大的擴充套件了Jenkins的功能；它們都是開源的，而且它們可以直接通過web介面來進行安裝與管理。

5.Jenkins的目標

Jenkins的主要目標是監控軟體開發流程，快速顯示問題。所以能保證開發人員以及相關人員省時省力提高開發效率。

CI系統在整個開發過程中的主要作用是控制：當系統在程式碼儲存庫中探測到修改時，它將執行構建的任務委託給構建過程本身。如果構建失敗了，那麼CI系統將通知相關人員，然後繼續監視儲存庫。它的角色看起來是被動的；但它確能快速反映問題。

特別是它具有以下優點：

• Jenkins一切配置都可以在web介面上完成。有些配置如MAVEN_HOME和Email，只需要配置一次，所有的專案就都能用。當然也可以通過修改XML進行配置。
• 支援Maven的模組(Module)，Jenkins對Maven做了優化，因此它能自動識別Module，每個Module可以配置成一個job。相當靈活。
• 測試報告聚合，所有模組的測試報告都被聚合在一起，結果一目瞭然，使用其他CI，這幾乎是件不可能完成的任務。
• 構件指紋(artifact fingerprint)，每次build的結果構件都被很好的自動管理，無需任何配置就可以方便的瀏覽下載。