什麼是CI/CD，你瞭解它給團隊帶來的收益和挑戰嗎？
來源 | Jenkins（ID：Jenkins-Community）
譯者 | 李煜東 & donghui
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 正在使用機器學習解決這個問題。
持續整合的收益與挑戰
毫無疑問，持續整合（ CI ）已成為一個軟體開發的主流原則。CI 的收益在業界眾所周知的，並且很難找到反對實施它的人。
在這裡，我想把那些收益收集起來放到一箇中心化的地方。但是我認為扮演反面角色並試圖找出持續整合的弊端或挑戰也是很有趣的。
從根本上說， 持續整合（ CI ）是一種開發實踐，開發人員每天都要將程式碼整合到共享的倉庫中。在該倉庫中，程式碼被自動構建進行驗證用來在這個流程中檢驗儘早的發現任何問題。這允許團隊花更少的時間回溯，而花更多的時間構建新特性。
持續整合的收益
1、緩解風險
據 Martin Fowler 說，持續整合的最大收益是減輕風險。由於延遲了程式碼整合，團隊將不斷增加合併衝突的數量和嚴重性。當團隊頻繁整合（使用自動構建），他們減輕了潛在風險的數量，因為他們總是知道系統的當前狀態。
2、質量保證
實施持續整合的團隊對他們的操作更有信心。他們知道自動構建會立即捕獲缺陷，這使他們能夠保證質量。他們也不會猜測系統中 bug 的數量，這允許他們能夠向隊友提供準確的數量，併為客戶提供更好的服務。
3、提高可見性和加強團隊合作
自動構建為團隊提供了對其系統的完全可見性。他們知道問題的數量，並能快速的解決問題。提高可見性可以讓團隊有機會在小問題變成大之前通過協作解決。
持續整合的挑戰
1、組織文化變革
一些企業更喜歡傳統的方法，並且可能很難實施持續整合。他們必須對員工進行再培訓，這就意味著要對現有的業務進行大修。管理者可能會抵制因為持續整合並不能幫助他們實現公司的直接目標（例如：金錢在質量之上）。
2、難以維護
構建一個自動化的程式碼倉庫不是一個簡單的任務。團隊必須構建適當的測試套件，並花時間編寫測試用例，而不是開發程式碼。起初，這可能會讓他們放慢速度，讓他們對按時完成自己的專案失去信心。如果測試套件不穩定，它可能在某些天內完美地工作，但其他天可能不起作用。然後團隊將不得不花費更多的時間來弄清楚發生了什麼。
3、大量的錯誤資訊
對於較大的開發團隊，他們可能每天都會看到 CI 錯誤訊息，並開始忽略它們，因為它們還有其他任務和關注點。他們可能會開始將一個破壞的構建視為一個正常的事情，並且缺陷可能開始堆積在一起。