【51CTO.com原創稿件】本文通過對持續集成相關概念和工具的全面介紹，幫助您在保證軟件質量的前提下，實現交付和部署的各項目標。

[[251659]]

近年來，軟件開發界流行的一些熱門詞匯莫過于：持續集成(Continuous Integration，CI)、持續交付(Continuous Delivery)、和持續部署(Continuous Deployment，CD)了，有時也被連起來稱為 CI/CD。

無論是單個人的開發作坊，還是大型的跨國公司，大家都在為他們的軟件產品實踐著 CI 和 CD。

在本文中，我們將和您探究 CI，并簡要介紹 CD，以及如何有效地使用它們。

同時，我們也會對那些能夠幫助您加速開發流程的熱門工具和系統進行評估。

持續集成：自動化開發流程和***實踐

為了闡明持續集成是如何能融入現代軟件環境中的，首先讓我們來簡單了解一下典型的軟件開發流程。

如今，無論是網站、智能手機應用、還是傳統的桌面應用程序，一般都會遵循如下精簡的開發流程：

• 開發人員編寫一段被稱為變更集或補丁的代碼，這些一般是針對某個項目的變更代碼庫(例如，增添新的功能、或是修復某個 Bug)。
• 他們將變更代碼整合(或合并)到為項目設立的集中式權威代碼存儲庫中(例如，GitHub 庫)。
• 如果與現有編程語言或應用相關，這些項目的源代碼會被編譯，然后被構建為可部署的版本，它們通常被稱為神器(artifacts 或工件)或包。

上述步驟是各種開發流程的簡化步驟，它們省略了一些對于分批部署的策略考慮。

在具體考慮該流程每個階段的責任時，我們很自然地會想到如下兩個關鍵問題：

• 在***步中，我們如何確保開發人員的變更集能夠與現有的項目相集成?任何變更不應破壞現有代碼庫，如：不可引入新的問題。

如何界定變更具有良好的代碼質量，我們在應用環境該如何判定呢?特別是那些與人身安全相關的醫療應用。

• 誰(或是什么工具)對于上述第二、三步進行管控和保障?

在 CI 的開發模式中，我們需要通過自動化來回答上述問題。例如：針對第二、三步，我們需要驗證開發人員的變更，是否能被主代碼庫所接受和集成，以及整個團隊能否成功完成項目的構建，并運行相關的測試。

因此，在一個理想的 CI 環境中，每一段代碼都是在開發的過程中被集成的。對于此類企業而言，每一天(更有甚者是每次提交)都會發生好幾次的代碼集成。

什么是持續交付和持續部署?

持續交付和持續部署將自動化帶到了一個新的高度，它們能夠將您最近一次提交的內容進行自動分發，并成為整個軟件的新版本。

持續交付：是指構建神器，并做好部署準備的過程。一般需要人工來判定是否的確需要部署。

持續部署：意味著所有流程都是自動的。即：在無人為干預的情況下，通過單次提交來觸發自動管道，并最終將您的應用生產環境更新為***版本的過程。

雖然有許多公司已經實現了持續交付，但是很少做到持續部署的。而且，持續部署是有風險的，因為任何人都有可能通過一個簡單的提交，就將 Bug 引入了生產環境。因此，我們需要通過流程來降低這種風險。

持續集成的好處

以往在非 CI 環境中，人們針對軟件項目，主要采用的是主干-分支(trunk-branch)式的版本控制。

開發人員長期在分支上開發各種功能。隨著時間的推移，他們在將自己的變更與其他開發人員集成時，往往會不知不覺地讓分支偏離了主干。

因此，為了確保所有的變更都能兼容生產系統，開發人員往往在整合分支功能的過程中苦不堪言，他們甚至創造了短語--“整合地獄(integration hell)”。

如今，CI 的工作流程正好能夠通過輕松、例行的集成方式，解決這個問題。

持續集成不但能夠節省開發人員的時間，避免他們手動整合的各種變更，還能提高軟件的可靠性。

開發團隊能夠籍此更有信心地通過編寫代碼(和相關的測試)，來增加新的功能，并向用戶自動推送發布。

持續集成實踐的前提

我們在采用持續集成的工作流程中，會涉及到如下必備的條件：

• 版本控制系統工具
• 構建工具
• 神器庫管理器(Artifacts Repository Manager)

持續集成依賴于版本控制系統

持續集成最重要的前提條件是對其代碼庫的版本控制，即：對于代碼庫的每一項變更，都必須被安全地存放到專有的版本控制系統(Concurrent Versions System，VCS)中。

一旦實現了代碼版本控制，我們就能用 CI 工具來進行訪問。在市場上盛行的 VCS 工具中，Git 是***的一款，我們下面來簡單介紹一下。

Git 最初是由 Linus Torvalds 為 Linux 內核所創建的，其主要特征包括：

• 支持非線性開發：Git 的分支(與合并)是在開發者的電腦上進行的。
• 分布式開發：每個開發人員都擁有整個存儲庫歷史記錄的本地拷貝。
• 對大型項目的有效處置：在處置大型代碼庫時，Git 能夠快速地執行性能測試。
• 用戶身份認證：通過加密和簽名，來實現對提交人的驗明正身。
• 對代碼歷史的加密認證：正如在區塊鏈中，某個特定提交的 ID 取決于其前面的內容那樣，在 Git 中改變歷史代碼后，其提交 ID 也會跟著變化。
• 垃圾收集：無用的對象會被自動進行垃圾收集。如果空間不足，您也能顯式地調用垃圾收集來清理某個 Git 存儲庫。

用構建工具實現持續集成

構建工具能夠通過處理應用的源代碼，自動生成所需的軟件。一般而言，軟件工具的構建步驟取決于所選用的技術棧。

下面是一個 Java 應用程序構建步驟的示例：

• 如有需要，根據現有配置生成 .java 的文件。
• 將源代碼(.java 文件)編譯成字節碼(.class 文件)。
• 將測試代碼編譯成字節碼。
• 執行各種單元測試。
• 按需進行集成測試。
• 將多個 .class 文件打包成一個 JAR 文檔。
• 按需將 JAR 文件存入神器庫管理器。
• 按需在控制系統版本中，對代碼做相應的標記。

對于上述例子，我們一般可用到如下的構建工具：

• Ant，針對 Java 技術的、且基于 XML 的跨平臺生成工具。
• Maven，是一種基于 XML 的廣泛聲明，它偏向于將約定優于配置。

上述兩種典型的構建工具和流程，都具有重復構建的能力。這意味著只要是一組相同的源代碼，就應該能產生相同的一組神器輸出。

例如：對于相同代碼庫，無論是開發人員用筆記本電腦進行構建、還是 CI 系統構建，它們都應當產生相同的結果。

這樣會帶來如下的好處：

• 首先，通過消除在開發人員筆記本和數據中心服務器上運行代碼的差異性，進而降低在開發環境和生產環境中運行可能產生的異常問題。您也不會再聽到“它在我的電腦上運行的時候是好好的啊!”之類的言論。
• 其次，如果在 CI 系統中通過了測試，那么由于運行的代碼是相同的，它就能***限度地減少生產環境的中斷。
• ***，如果它們能夠以一種一致的、且可重復的方式構建的話，必定能提高神器的緩存效率，并能在不同階段共享二進制文件。

用神器庫管理器存儲各種持續集成過程的結果

正如源代碼需要被存儲在 VCS 中那樣，那些能夠產生構建過程的神器同樣需要被存儲在某個遠程文件系統中。

因此，我們可以使用專用的軟件，如二進制庫管理器(Binary Repository Manager)來管理神器。

維基百科是這樣定義二進制庫管理器的：它是一種軟件工具，旨在優化下載和存儲那些在軟件開發的過程中所產生和使用到的二進制文件。它被組織用來集中式管理二進制的神器，從而克服多種二進制神器類型的復雜性，進而減少整個工作流之間的依賴關系。

可見，神器庫管理器具有如下主要功能：

• 緩存：由于庫管理器會被安裝在公司系統內，因此開發人員訪問它的速度比遠程訪問更快。
• 通過被設為代理服務器，它能夠緩存那些已下載的第三方神器，并加快對其訪問。
• 保存策略：庫管理器能夠自動清空閑置的神器，以收回寶貴的空間。
• 高可用性：由于庫管理器的掉線勢必會影響到企業項目構建的平穩運行，因此我們可以把庫管理器組建成為群集，以便開發人員和 CI 工具隨時訪問。

用戶限制：***庫管理器能夠通過限制訪問權限，來為神器制定對應的用戶和組。

從開發到真實構建的簡單 CI 工作流

由于不同企業所使用的軟件、堆棧和用例有所不同，他們的 CI 工作流也可能各式各樣。

下面讓我們以一個簡單工作流為例，探討一下從開始研發到真正構建的自動化過程。

分支

我們一般有兩種從代碼庫獲取***拷貝的可能：

• 如果是***訪問的話，您需要進行“下載”。即：使用 git clone 命令，拷貝 Git 的遠程代碼庫到本地。
• 如果代碼庫已經存在本地，您可以使用類似 git pull 的命令，將其與遠程存儲庫同步。

在版本控制系統中，有一個專有的分支可以指向軟件的***、且穩定的版本(通常被稱為 master 版本)，這個版本正是我們需要發布到生產環境中的。

為了保留這個黃金標準(gold standard)版本，并避免出現各種的 Bug，我們不應該對它進行直接的寫操作。因此，每一次開發都應該從 master 版本里創建一個專有的分支開始。

同時，為了保持代碼的井井有條，我們還應當盡可能地對分支采取有命名規則的方案，其中常用到的前綴包括：develop、feature、release 和 hotfix 等。

測試

根據具體情況的不同，測試方案既可以被事先編寫，即：測試驅動型設計(Test-Driven Design);也可以在代碼完成后再編寫。無論是之前還是之后，我們都需要通過回歸測試來保證代碼的穩定運行。

測試代碼的覆蓋率也應當視具體情況而定：對于涉及到人類生命的軟件，如飛機導航或手術輔助，其每一行代碼都需要被檢查(甚至要二重、或三重檢查)。而在其他情況下，測試的覆蓋率就不一定那么高了。

拉式請求(Pull Request)

記住，不要對 master 進行直接變更，而應該在某個專門的分支上進行。一旦開發完成，團隊成員就應該考慮是否要將變更合并到主分支上。

因此，拉式請求的目標就是：您去詢問自己的團隊是否將變更接納成為黃金標準，并且開放您的補丁包供他人評審。

而一旦拉式請求被開啟，分支就會自動使用項目的構建工具進行構建，并確保變更不會破壞我們的主分支。

質量保證

一般情況下，我們還會伴隨進行其他步驟，包括：對提交的代碼進行安全性、代碼質量、文檔標準等方面的自動審核。

說到代碼質量，就不得不提及該領域的知名開源平臺 SonarQube(https://www.sonarqube.org/)。

SonarQube 能夠與各大主流 CI 工具相集成，對某個代碼庫執行配置檢查。

下面是對于持續檢查(Continuous Inspection)的詮釋：SonarQube 不僅能夠展示某個應用程序的健康狀態，還能突顯各種新引入的問題。通過質量門(Quality Gate)，您可以修復漏洞，進而系統地提高代碼的質量。

構建

拉式請求一旦啟動，自動構建就會通過各種 CI 工具，自動進行編譯、測試、打包等步驟。

當然，如果一個(或多個)自動構建步驟出現失敗，我們則認為整個構建失敗。

在大多數 CI 工具中，失敗的構建會以紅色顯示，而綠色則表示已經順利通過的構建。

因此，您可能會聽到有人將已通過的構建稱為“綠色構建(green build)”。相反，如果構建失敗，則無論是什么原因，都會返回給處于拉式請求之初的開發人員予以修復。

代碼審查

雖然諸如 SonarQube 之類的工具可以檢測一些簡單的錯誤模式，如雙重檢查鎖定(Double Checked Locking，https://fr.wikipedia.org/wiki/Double-checked_locking)，但是更復雜的 Bug 還是需人工進行代碼審查的。

因此，將代碼變更合并到 master 之前的***一步便是：團隊成員的手動代碼審查(這正是拉式請求的意義所在)。

不同的開發人員會有不同的代碼審查方式。但是我建議您從基礎方面做起，例如，您可以參考：代碼審查到底要查什么?(https://leanpub.com/whattolookforinacodereview)。

標記、版本控制和存儲構建神器

代碼變更終于在這個階段以 hot-fix 的形式被合入 master 并發布了。而 CI 工具也會再進行一次構建的重放，以確保萬無一失。

首先，VCS 需要對版本打上相應的版本標簽。雖然在企業實際開發過程中，大家常會以某個山名、湖名、甚至是蛋糕名字，來增加創意性，例如：Ubuntu 的“Placid Pangolin”和安卓的“Oreo”。

但是從原理上說，軟件開發者應該采用一套標準的版本控制方案和命名規則(如使用數字編號)，通過遵循規范的語義版本，來區分和定義 major、minor 和 bugfix 版本。如你想了解更多信息，請參見 semver.org。

其次，通過構建所產生的神器應當被存儲到神器庫管理器之中。籍此，當出現異常情況需要執行“回滾”操作時，您可以直接使用以前的工作版本，而無需對源代碼進行重新構建。

持續集成工具概述

隨著持續集成的廣泛應用，與之相關工具的生態系統也日趨成熟。下面我們來討論一些目前最為流行和常用的 CI/CD 系統。

它們的用戶既有完全依賴云服務運營的初創企業，也有在自己內部使用復雜 CI 平臺的大型組織。

Jenkins

Jenkins 是持續集成領域最老牌、且最被廣泛應用的開源項目之一。該工具利弊共存：多年來，其核心架構已經歷了從小型部署到大公司生產環境的多種“實戰”檢驗。

另外，Jenkins 擁有一個“充滿活力”的在線用戶社區，能夠幫助您為各種問題尋求解決方案。

當然，它的內部抽象機制可能對于一些具有大型遺留代碼庫、和向后兼容性的需求有些過時，并可能會經常出現跨不同用戶場景的泄漏現象。

此外，盡管 Jenkins 擁有著廣泛的插件生態系統，并提供了許多時髦的功能，但是由于這些插件通常是由社區所開發，因此質量和可靠性參差不齊。

近年來，Jenkins 常被描述為持續集成的工作流，即：管道(pipelines，請參見：https://jenkins.io/doc/book/pipeline/)。

開發人員能夠用它來聲明和描述與構建和部署有關的過程。而且，Jenkins 還允許您創建一些能夠在不同項目中，通過重用來規范和簡化通用流程的不同模塊。

總之，Jenkins 擁有悠久的開發和應用歷史，以及龐大且活躍的社區支持，同時它能夠被高度定制。可以說，開發人員一旦掌握了它，就遠離了失業的風險。

Travis CI

Travis CI 與 Jenkins 幾乎處于同樣的地位。雖然它有著許多開源的組件，但是如果缺少了企業賬號，您將無法采用自托管的模式。不過，使用任何開源項目來運行 Travis 都是免費的。

Travis 運行的每個任務都必須被包含在 travis.yml 中，而該文件也需要被載入到您的代碼段中。這就意味著您可以從一個存儲庫的不同分支上運行不同的任務。

Travis 的宗旨是簡單化。您可以從 GitHub 托管庫中直接工作，并在許多應用中維護一個通用的服務庫。

當然，如果您沒有用到 GitHub、或是需要有更多的控制，那么 Travis 可能就不適合您了。

Travis 的一個實用功能是能夠在多種操作系統上運行，即：您可以在不同的目標系統上測試自己的代碼，而無需維護各種虛擬機或鏡像。

GitLab 持續集成/持續交付

GitLab 源于一項源碼托管的服務。它與 GitHub 有類似之處，同時也提供一個開源的版本。

不過，與 GitHub 的不同之處在于：GitLab 包括一個內置于平臺之中的，被稱為 AutoDevOps 的高級 CI/CD 實現。

對于已經使用 GitLab 來存儲源代碼的用戶來說，這種緊密集成是 GitLab 在 CI/CD 上能夠提供的最實用的功能之一。

您可以通過在源代碼庫的根目錄上添加 .gitlab-ci.yml 配置文件，來啟用它。當然，您也可以將 GitLab 的 CI/CD 與 GitHub 的存儲庫相集成。

Bamboo

Bamboo 是 Atlassian 公司的持續集成/持續交付產品。該公司的另一個知名軟件產品是 JIRA —一種 Bug 跟蹤軟件。

Bamboo 的主要優勢在于：它能與那些已經在自己的系統中使用的其他 Atlassian 產品(如 JIRA 和 Bitbucket)緊密集成。

不過，相比其擁有大量插件市場的優勢，Bamboo 的用戶社區規模不算大，因此用戶需要更加依賴于 Atlassian 本身的支持。

CircleCI

CircleCI 是一種在線服務，它提供了強大的 CI 平臺，當然它也提供主機托管版本。

CircleCI 平臺主要服務于容器，并能為測試提供快速的擴展(spin-up)。它的工作流功能，允許用戶為復雜的項目自定義 CI 和 CD 的作業序列。

CircleCI 的主要優點是：它是一個全托管式的 CI 解決方案，因此減少了最終用戶花費在系統維護上的時間。

結論

僅靠選對了持續集成的***實踐和工具，我們是無法保證能夠將自己的組織帶入 CI 正軌的。

對于許多傳統的軟件企業而言，他們還需要整個軟件開發團隊在協作方式上的轉變。

為了能夠成功地將一整套變更集整合到代碼庫中，團隊成員應當事先約定好各種工作模式和規范，并能夠堅持執行。

要想實現可靠的構建步驟，團隊成員有時候要對生產環境中的各種問題進行嚴格的重構和持續的部署，進而拓寬整個團隊在設計上的視野。 

綜上所述，持續集成能夠給軟件組織帶來的好處是不言而喻的。如今它已經成為了新的軟件規范，企業必將通過不斷的 CI 實踐，以加速項目的交付和質量的提升。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】