【51CTO.com原創(chuàng)稿件】本文通過對(duì)持續(xù)集成相關(guān)概念和工具的全面介紹，幫助您在保證軟件質(zhì)量的前提下，實(shí)現(xiàn)交付和部署的各項(xiàng)目標(biāo)。

[[251659]]

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

無論是單個(gè)人的開發(fā)作坊，還是大型的跨國公司，大家都在為他們的軟件產(chǎn)品實(shí)踐著 CI 和 CD。

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

同時(shí)，我們也會(huì)對(duì)那些能夠幫助您加速開發(fā)流程的熱門工具和系統(tǒng)進(jìn)行評(píng)估。

持續(xù)集成：自動(dòng)化開發(fā)流程和***實(shí)踐

為了闡明持續(xù)集成是如何能融入現(xiàn)代軟件環(huán)境中的，首先讓我們來簡(jiǎn)單了解一下典型的軟件開發(fā)流程。

如今，無論是網(wǎng)站、智能手機(jī)應(yīng)用、還是傳統(tǒng)的桌面應(yīng)用程序，一般都會(huì)遵循如下精簡(jiǎn)的開發(fā)流程：

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

上述步驟是各種開發(fā)流程的簡(jiǎn)化步驟，它們省略了一些對(duì)于分批部署的策略考慮。

在具體考慮該流程每個(gè)階段的責(zé)任時(shí)，我們很自然地會(huì)想到如下兩個(gè)關(guān)鍵問題：

• 在***步中，我們?nèi)绾未_保開發(fā)人員的變更集能夠與現(xiàn)有的項(xiàng)目相集成?任何變更不應(yīng)破壞現(xiàn)有代碼庫，如：不可引入新的問題。

如何界定變更具有良好的代碼質(zhì)量，我們?cè)趹?yīng)用環(huán)境該如何判定呢?特別是那些與人身安全相關(guān)的醫(yī)療應(yīng)用。

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

在 CI 的開發(fā)模式中，我們需要通過自動(dòng)化來回答上述問題。例如：針對(duì)第二、三步，我們需要驗(yàn)證開發(fā)人員的變更，是否能被主代碼庫所接受和集成，以及整個(gè)團(tuán)隊(duì)能否成功完成項(xiàng)目的構(gòu)建，并運(yùn)行相關(guān)的測(cè)試。

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

什么是持續(xù)交付和持續(xù)部署?

持續(xù)交付和持續(xù)部署將自動(dòng)化帶到了一個(gè)新的高度，它們能夠?qū)⒛罱淮翁峤坏膬?nèi)容進(jìn)行自動(dòng)分發(fā)，并成為整個(gè)軟件的新版本。

持續(xù)交付：是指構(gòu)建神器，并做好部署準(zhǔn)備的過程。一般需要人工來判定是否的確需要部署。

持續(xù)部署：意味著所有流程都是自動(dòng)的。即：在無人為干預(yù)的情況下，通過單次提交來觸發(fā)自動(dòng)管道，并最終將您的應(yīng)用生產(chǎn)環(huán)境更新為***版本的過程。

雖然有許多公司已經(jīng)實(shí)現(xiàn)了持續(xù)交付，但是很少做到持續(xù)部署的。而且，持續(xù)部署是有風(fēng)險(xiǎn)的，因?yàn)槿魏稳硕加锌赡芡ㄟ^一個(gè)簡(jiǎn)單的提交，就將 Bug 引入了生產(chǎn)環(huán)境。因此，我們需要通過流程來降低這種風(fēng)險(xiǎn)。

持續(xù)集成的好處

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

開發(fā)人員長期在分支上開發(fā)各種功能。隨著時(shí)間的推移，他們?cè)趯⒆约旱淖兏c其他開發(fā)人員集成時(shí)，往往會(huì)不知不覺地讓分支偏離了主干。

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

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

持續(xù)集成不但能夠節(jié)省開發(fā)人員的時(shí)間，避免他們手動(dòng)整合的各種變更，還能提高軟件的可靠性。

開發(fā)團(tuán)隊(duì)能夠籍此更有信心地通過編寫代碼(和相關(guān)的測(cè)試)，來增加新的功能，并向用戶自動(dòng)推送發(fā)布。

持續(xù)集成實(shí)踐的前提

我們?cè)诓捎贸掷m(xù)集成的工作流程中，會(huì)涉及到如下必備的條件：

• 版本控制系統(tǒng)工具
• 構(gòu)建工具
• 神器庫管理器(Artifacts Repository Manager)

持續(xù)集成依賴于版本控制系統(tǒng)

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

一旦實(shí)現(xiàn)了代碼版本控制，我們就能用 CI 工具來進(jìn)行訪問。在市場(chǎng)上盛行的 VCS 工具中，Git 是***的一款，我們下面來簡(jiǎn)單介紹一下。

Git 最初是由 Linus Torvalds 為 Linux 內(nèi)核所創(chuàng)建的，其主要特征包括：

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

用構(gòu)建工具實(shí)現(xiàn)持續(xù)集成

構(gòu)建工具能夠通過處理應(yīng)用的源代碼，自動(dòng)生成所需的軟件。一般而言，軟件工具的構(gòu)建步驟取決于所選用的技術(shù)棧。

下面是一個(gè) Java 應(yīng)用程序構(gòu)建步驟的示例：

• 如有需要，根據(jù)現(xiàn)有配置生成 .java 的文件。
• 將源代碼(.java 文件)編譯成字節(jié)碼(.class 文件)。
• 將測(cè)試代碼編譯成字節(jié)碼。
• 執(zhí)行各種單元測(cè)試。
• 按需進(jìn)行集成測(cè)試。
• 將多個(gè) .class 文件打包成一個(gè) JAR 文檔。
• 按需將 JAR 文件存入神器庫管理器。
• 按需在控制系統(tǒng)版本中，對(duì)代碼做相應(yīng)的標(biāo)記。

對(duì)于上述例子，我們一般可用到如下的構(gòu)建工具：

• Ant，針對(duì) Java 技術(shù)的、且基于 XML 的跨平臺(tái)生成工具。
• Maven，是一種基于 XML 的廣泛聲明，它偏向于將約定優(yōu)于配置。

上述兩種典型的構(gòu)建工具和流程，都具有重復(fù)構(gòu)建的能力。這意味著只要是一組相同的源代碼，就應(yīng)該能產(chǎn)生相同的一組神器輸出。

例如：對(duì)于相同代碼庫，無論是開發(fā)人員用筆記本電腦進(jìn)行構(gòu)建、還是 CI 系統(tǒng)構(gòu)建，它們都應(yīng)當(dāng)產(chǎn)生相同的結(jié)果。

這樣會(huì)帶來如下的好處：

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

用神器庫管理器存儲(chǔ)各種持續(xù)集成過程的結(jié)果

正如源代碼需要被存儲(chǔ)在 VCS 中那樣，那些能夠產(chǎn)生構(gòu)建過程的神器同樣需要被存儲(chǔ)在某個(gè)遠(yuǎn)程文件系統(tǒng)中。

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

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

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

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

用戶限制：***庫管理器能夠通過限制訪問權(quán)限，來為神器制定對(duì)應(yīng)的用戶和組。

從開發(fā)到真實(shí)構(gòu)建的簡(jiǎn)單 CI 工作流

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

下面讓我們以一個(gè)簡(jiǎn)單工作流為例，探討一下從開始研發(fā)到真正構(gòu)建的自動(dòng)化過程。

分支

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

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

在版本控制系統(tǒng)中，有一個(gè)專有的分支可以指向軟件的***、且穩(wěn)定的版本(通常被稱為 master 版本)，這個(gè)版本正是我們需要發(fā)布到生產(chǎn)環(huán)境中的。

為了保留這個(gè)黃金標(biāo)準(zhǔn)(gold standard)版本，并避免出現(xiàn)各種的 Bug，我們不應(yīng)該對(duì)它進(jìn)行直接的寫操作。因此，每一次開發(fā)都應(yīng)該從 master 版本里創(chuàng)建一個(gè)專有的分支開始。

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

測(cè)試

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

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

拉式請(qǐng)求(Pull Request)

記住，不要對(duì) master 進(jìn)行直接變更，而應(yīng)該在某個(gè)專門的分支上進(jìn)行。一旦開發(fā)完成，團(tuán)隊(duì)成員就應(yīng)該考慮是否要將變更合并到主分支上。

因此，拉式請(qǐng)求的目標(biāo)就是：您去詢問自己的團(tuán)隊(duì)是否將變更接納成為黃金標(biāo)準(zhǔn)，并且開放您的補(bǔ)丁包供他人評(píng)審。

而一旦拉式請(qǐng)求被開啟，分支就會(huì)自動(dòng)使用項(xiàng)目的構(gòu)建工具進(jìn)行構(gòu)建，并確保變更不會(huì)破壞我們的主分支。

質(zhì)量保證

一般情況下，我們還會(huì)伴隨進(jìn)行其他步驟，包括：對(duì)提交的代碼進(jìn)行安全性、代碼質(zhì)量、文檔標(biāo)準(zhǔn)等方面的自動(dòng)審核。

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

SonarQube 能夠與各大主流 CI 工具相集成，對(duì)某個(gè)代碼庫執(zhí)行配置檢查。

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

構(gòu)建

拉式請(qǐng)求一旦啟動(dòng)，自動(dòng)構(gòu)建就會(huì)通過各種 CI 工具，自動(dòng)進(jìn)行編譯、測(cè)試、打包等步驟。

當(dāng)然，如果一個(gè)(或多個(gè))自動(dòng)構(gòu)建步驟出現(xiàn)失敗，我們則認(rèn)為整個(gè)構(gòu)建失敗。

在大多數(shù) CI 工具中，失敗的構(gòu)建會(huì)以紅色顯示，而綠色則表示已經(jīng)順利通過的構(gòu)建。

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

代碼審查

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

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

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

標(biāo)記、版本控制和存儲(chǔ)構(gòu)建神器

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

首先，VCS 需要對(duì)版本打上相應(yīng)的版本標(biāo)簽。雖然在企業(yè)實(shí)際開發(fā)過程中，大家常會(huì)以某個(gè)山名、湖名、甚至是蛋糕名字，來增加創(chuàng)意性，例如：Ubuntu 的“Placid Pangolin”和安卓的“Oreo”。

但是從原理上說，軟件開發(fā)者應(yīng)該采用一套標(biāo)準(zhǔn)的版本控制方案和命名規(guī)則(如使用數(shù)字編號(hào))，通過遵循規(guī)范的語義版本，來區(qū)分和定義 major、minor 和 bugfix 版本。如你想了解更多信息，請(qǐng)參見 semver.org。

其次，通過構(gòu)建所產(chǎn)生的神器應(yīng)當(dāng)被存儲(chǔ)到神器庫管理器之中。籍此，當(dāng)出現(xiàn)異常情況需要執(zhí)行“回滾”操作時(shí)，您可以直接使用以前的工作版本，而無需對(duì)源代碼進(jìn)行重新構(gòu)建。

持續(xù)集成工具概述

隨著持續(xù)集成的廣泛應(yīng)用，與之相關(guān)工具的生態(tài)系統(tǒng)也日趨成熟。下面我們來討論一些目前最為流行和常用的 CI/CD 系統(tǒng)。

它們的用戶既有完全依賴云服務(wù)運(yùn)營的初創(chuàng)企業(yè)，也有在自己內(nèi)部使用復(fù)雜 CI 平臺(tái)的大型組織。

Jenkins

Jenkins 是持續(xù)集成領(lǐng)域最老牌、且最被廣泛應(yīng)用的開源項(xiàng)目之一。該工具利弊共存：多年來，其核心架構(gòu)已經(jīng)歷了從小型部署到大公司生產(chǎn)環(huán)境的多種“實(shí)戰(zhàn)”檢驗(yàn)。

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

當(dāng)然，它的內(nèi)部抽象機(jī)制可能對(duì)于一些具有大型遺留代碼庫、和向后兼容性的需求有些過時(shí)，并可能會(huì)經(jīng)常出現(xiàn)跨不同用戶場(chǎng)景的泄漏現(xiàn)象。

此外，盡管 Jenkins 擁有著廣泛的插件生態(tài)系統(tǒng)，并提供了許多時(shí)髦的功能，但是由于這些插件通常是由社區(qū)所開發(fā)，因此質(zhì)量和可靠性參差不齊。

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

開發(fā)人員能夠用它來聲明和描述與構(gòu)建和部署有關(guān)的過程。而且，Jenkins 還允許您創(chuàng)建一些能夠在不同項(xiàng)目中，通過重用來規(guī)范和簡(jiǎn)化通用流程的不同模塊。

總之，Jenkins 擁有悠久的開發(fā)和應(yīng)用歷史，以及龐大且活躍的社區(qū)支持，同時(shí)它能夠被高度定制?？梢哉f，開發(fā)人員一旦掌握了它，就遠(yuǎn)離了失業(yè)的風(fēng)險(xiǎn)。

Travis CI

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

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

Travis 的宗旨是簡(jiǎn)單化。您可以從 GitHub 托管庫中直接工作，并在許多應(yīng)用中維護(hù)一個(gè)通用的服務(wù)庫。

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

Travis 的一個(gè)實(shí)用功能是能夠在多種操作系統(tǒng)上運(yùn)行，即：您可以在不同的目標(biāo)系統(tǒng)上測(cè)試自己的代碼，而無需維護(hù)各種虛擬機(jī)或鏡像。

GitLab 持續(xù)集成/持續(xù)交付

GitLab 源于一項(xiàng)源碼托管的服務(wù)。它與 GitHub 有類似之處，同時(shí)也提供一個(gè)開源的版本。

不過，與 GitHub 的不同之處在于：GitLab 包括一個(gè)內(nèi)置于平臺(tái)之中的，被稱為 AutoDevOps 的高級(jí) CI/CD 實(shí)現(xiàn)。

對(duì)于已經(jīng)使用 GitLab 來存儲(chǔ)源代碼的用戶來說，這種緊密集成是 GitLab 在 CI/CD 上能夠提供的最實(shí)用的功能之一。

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

Bamboo

Bamboo 是 Atlassian 公司的持續(xù)集成/持續(xù)交付產(chǎn)品。該公司的另一個(gè)知名軟件產(chǎn)品是 JIRA —一種 Bug 跟蹤軟件。

Bamboo 的主要優(yōu)勢(shì)在于：它能與那些已經(jīng)在自己的系統(tǒng)中使用的其他 Atlassian 產(chǎn)品(如 JIRA 和 Bitbucket)緊密集成。

不過，相比其擁有大量插件市場(chǎng)的優(yōu)勢(shì)，Bamboo 的用戶社區(qū)規(guī)模不算大，因此用戶需要更加依賴于 Atlassian 本身的支持。

CircleCI

CircleCI 是一種在線服務(wù)，它提供了強(qiáng)大的 CI 平臺(tái)，當(dāng)然它也提供主機(jī)托管版本。

CircleCI 平臺(tái)主要服務(wù)于容器，并能為測(cè)試提供快速的擴(kuò)展(spin-up)。它的工作流功能，允許用戶為復(fù)雜的項(xiàng)目自定義 CI 和 CD 的作業(yè)序列。

CircleCI 的主要優(yōu)點(diǎn)是：它是一個(gè)全托管式的 CI 解決方案，因此減少了最終用戶花費(fèi)在系統(tǒng)維護(hù)上的時(shí)間。

結(jié)論

僅靠選對(duì)了持續(xù)集成的***實(shí)踐和工具，我們是無法保證能夠?qū)⒆约旱慕M織帶入 CI 正軌的。

對(duì)于許多傳統(tǒng)的軟件企業(yè)而言，他們還需要整個(gè)軟件開發(fā)團(tuán)隊(duì)在協(xié)作方式上的轉(zhuǎn)變。

為了能夠成功地將一整套變更集整合到代碼庫中，團(tuán)隊(duì)成員應(yīng)當(dāng)事先約定好各種工作模式和規(guī)范，并能夠堅(jiān)持執(zhí)行。

要想實(shí)現(xiàn)可靠的構(gòu)建步驟，團(tuán)隊(duì)成員有時(shí)候要對(duì)生產(chǎn)環(huán)境中的各種問題進(jìn)行嚴(yán)格的重構(gòu)和持續(xù)的部署，進(jìn)而拓寬整個(gè)團(tuán)隊(duì)在設(shè)計(jì)上的視野。 

綜上所述，持續(xù)集成能夠給軟件組織帶來的好處是不言而喻的。如今它已經(jīng)成為了新的軟件規(guī)范，企業(yè)必將通過不斷的 CI 實(shí)踐，以加速項(xiàng)目的交付和質(zhì)量的提升。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】