1、什么是CI/CD？

本文介紹了 CI/CD 的概念及應用場景

CI/CD 的出現改變了開發人員和測試人員發布軟件的方式。本文是描述這一變化的系列文章第一篇， 這些文章將提供各種工具和流程的講解，以幫助開發人員更好的使用 CI/CD。

從最初的瀑布模型， 到后來的敏捷開發， 再到今天的DevOps， 這是現代開發人員構建出色產品的技術路線。 隨著 DevOps 的興起，出現了持續集成，持續交付（CI/CD）和持續部署的新方法， 而傳統的軟件開發和交付方式在迅速變得過時。過去的敏捷時代里， 大多數公司的軟件發布周期是每月、每季度甚至每年（還記得那些日子嗎？）， 而在現在 DevOps 時代，每周、每天甚至每天多次都是常態。 當 SaaS 成為業界主流后尤其如此，您可以輕松地動態更新應用程序， 而無需強迫用戶下載更新組件。很多時候，用戶甚至都不會注意到正在發生變化。

開發團隊通過軟件交付流水線（Pipeline）實現自動化，以縮短交付周期， 大多數團隊都有自動化流程來檢查代碼并部署到新環境。 我們一直在關注自動化測試流程，但這將在之后的文章中介紹。 今天，我們將介紹什么是 CI/CD/CD ，以及現代軟件公司如何使用工具將部署代碼的流程自動化。

持續集成注重將各個開發者的工作集合到一個代碼倉庫中，通常每天會進行幾次， 主要目的是盡早發現集成錯誤，使團隊更加緊密結合，更好地協作。持續交付的目的是最小化部署或發布過程中團隊固有的摩擦， 它的實現通常能夠將構建部署的每個步驟自動化，以便任何時刻能夠安全地完成代碼發布（理想情況下）。持續部署是一種更高程度的自動化，無論何時代碼有較大改動， 都會自動進行構建／部署。

以上的每一個階段都是交付流水線的一部分。Humble 和 Ferley在他們的書作《持續交付：通過自動化構建、測試和部署實現可靠軟件版本發布》中解釋說： 「對軟件的每次更改都要經過一個復雜的過程才能發布，該過程包括多個測試和部署階段進行軟件的構建。 反過來看，這個過程需要許多人之間的合作，甚至可能需要幾個團隊間合作。 部署流水線對這一過程進行建模，并且它的持續集成和發布管理工具能讓您在代碼從版本控制轉移到各種測試和部署時， 查看和控制每次更改的過程。」

持續集成（CI）

通過持續集成，開發人員能夠頻繁地將其代碼集成到公共代碼倉庫的主分支中。 開發人員能夠在任何時候多次向倉庫提交作品，而不是獨立地開發每個功能模塊并在開發周期結束時一一提交。

這里的一個重要思想就是讓開發人員更快更、頻繁地做到這一點，從而降低集成的開銷。 實際情況中，開發人員在集成時經常會發現新代碼和已有代碼存在沖突。 如果集成較早并更加頻繁，那么沖突將更容易解決且執行成本更低。

當然，這里也有一些權衡，這個流程不提供額外的質量保障。 事實上，許多組織發現這樣的集成方式開銷更大，因為它們依賴人工確保新代碼不會引起新的 bug 或者破壞現有代碼。 為了減少集成期間的摩擦，持續集成依賴于測試套件和自動化測試。 然而，要認識到自動化測試和持續測試是完全不同的這一點很重要，我們會在文章結尾處詳細說明。

CI 的目標是將集成簡化成一個簡單、易于重復的日常開發任務， 這樣有助于降低總體的構建成本并在開發周期的早期發現缺陷。 要想有效地使用 CI 必須轉變開發團隊的習慣，要鼓勵頻繁迭代構建， 并且在發現 bug 的早期積極解決。

持續交付（CD）實際上是 CI 的擴展，其中軟件交付流程進一步自動化，以便隨時輕松地部署到生成環境中。 成熟的持續交付方案也展示了一個始終可部署的代碼庫。使用 CD 后，軟件發布將成為一個沒有任何緊張感的例行事件。 開發團隊可以在日常開發的任何時間進行產品級的發布，而不需要詳細的發布方案或者特殊的后期測試。

CD 集中依賴于部署流水線，團隊通過流水線自動化測試和部署過程。此流水線是一個自動化系統， 可以針對構建執行一組漸進的測試套件。CD 具有高度的自動化，并且在一些云計算環境中也易于配置。

在流水線的每個階段，如果構建無法通過關鍵測試會向團隊發出警報。否則，將繼續進入下一個測試， 并在連續通過測試后自動進入下一個階段。流水線的最后一個部分會將構建部署到和生產環境等效的環境中。 這是一個整體的過程，因為構建、部署和環境都是一起執行和測試的，它能讓構建在實際的生產環境可部署和可驗證。

AWS 上提供了可靠的當前 CI/CD 的展示，亞馬遜是云計算的提供商之一，提供出色的 CI/CD 流水線環境和實驗過程， 有眾多開發資源可供選擇，您可以將它們在一個易于配置和監控的流水線中組合起來。

許多人認為持續交付的吸引力主要在于，它自動化了從提交代碼到倉庫，再到測試和發布產品過程的所有步驟。 這是構建和測試過程細致的自動化，但是如何發布以及發布什么仍然是需要人工操作，持續部署可以改變這一點。

持續部署（CD）

持續部署擴展了持續交付，以便軟件構建在通過所有測試時自動部署。在這樣的流程中， 不需要人為決定何時及如何投入生產環境。CI/CD 系統的最后一步將在構建后的組件/包退出流水線時自動部署。 此類自動部署可以配置為快速向客戶分發組件、功能模塊或修復補丁，并準確說明當前提供的內容。

采用持續部署的組織可以將新功能快速傳遞給用戶，得到用戶對于新版本的快速反饋，并且可以迅速處理任何明顯的缺陷。 用戶對無用或者誤解需求的功能的快速反饋有助于團隊規劃投入，避免將精力集中于不容易產生回報的地方。

隨著 DevOps 的發展，新的用來實現 CI/CD 流水線的自動化工具也在不斷涌現。這些工具通常能與各種開發工具配合， 包括像 GitHub 這樣的代碼倉庫和 Jira 這樣的 bug 跟蹤工具。此外，隨著 SaaS 這種交付方式變得更受歡迎， 許多工具都可以在現代開發人員運行應用程序的云環境中運行，例如GCP和 AWS。

最受歡迎的自動化工具是Jenkins（以前的 Hudson）， 這是一個由數百名貢獻者和商業公司Cloudbees支持的開源項目。 Cloudbees 甚至聘請了 Jenkins 的創始人，并提供了一些 Jenkins 培訓項目和附加組件。 除了開源項目之外，還有一些更現代化的商業產品例如 CircleCI，Codeship 和 Shippable。 這些產品各有優缺點，我鼓勵開發人員在開發流程中一一嘗試它們，以了解它們在您的環境中的工作方式， 以及它們如何與您的工具、云平臺、容器系統等協作。

在 mabl 中，我們在Google Cloud Platform 上進行構建， 因此，我們正在尋找與 GSP 兼容或者最好是已經集成進 GSO 的產品。我們嘗試過 CircleCI，Codeship 和 Shippable， 下面有一個簡單的表格，展示了每個工具的一些細節：

我們最終選擇了Codeship，我認為我們的選擇是正確的， 也感謝 Codeship 團隊的支持。

接下來？

一旦部署了現代化的 CI/CD 流水線，您可能會意識到開發人員工作流程中的一些工具和流程也需要進行現代化改造。 測試是一個要著重關注的領域，如果您的部署頻率是每天或者一天多次，您的每次測試可能需要數小時甚至一晚上才能完成。 mabl 正在使用機器學習解決這個問題。

轉載：https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-12-what-is-cicd/

原文作者：Izzyazeri

鏈接：https://dzone.com/articles/what-is-cicd

總結

以上是生活随笔為你收集整理的什么是CI/CD？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。