建站
咨詢
售后
建站咨詢
新聞中心
【稿件】本文通過對持續(xù)集成相關概念和工具的全面介紹，幫助您在保證軟件質量的前提下，實現(xiàn)交付和部署的各項目標。
創(chuàng)新互聯(lián)主營岢嵐網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,重慶APP軟件開發(fā),岢嵐h5小程序開發(fā)搭建,岢嵐網(wǎng)站營銷推廣歡迎岢嵐等地區(qū)企業(yè)咨詢
近年來，軟件開發(fā)界流行的一些熱門詞匯莫過于：持續(xù)集成(Continuous Integration，CI)、持續(xù)交付(Continuous Delivery)、和持續(xù)部署(Continuous Deployment，CD)了，有時也被連起來稱為 CI/CD。
無論是單個人的開發(fā)作坊，還是大型的跨國公司，大家都在為他們的軟件產(chǎn)品實踐著 CI 和 CD。
在本文中，我們將和您探究 CI，并簡要介紹 CD，以及如何有效地使用它們。
同時，我們也會對那些能夠幫助您加速開發(fā)流程的熱門工具和系統(tǒng)進行評估。
持續(xù)集成：自動化開發(fā)流程和***實踐
為了闡明持續(xù)集成是如何能融入現(xiàn)代軟件環(huán)境中的，首先讓我們來簡單了解一下典型的軟件開發(fā)流程。
如今，無論是網(wǎng)站、智能手機應用、還是傳統(tǒng)的桌面應用程序，一般都會遵循如下精簡的開發(fā)流程：
- 開發(fā)人員編寫一段被稱為變更集或補丁的代碼，這些一般是針對某個項目的變更代碼庫(例如，增添新的功能、或是修復某個 Bug)。
- 他們將變更代碼整合(或合并)到為項目設立的集中式權威代碼存儲庫中(例如，GitHub 庫)。
- 如果與現(xiàn)有編程語言或應用相關，這些項目的源代碼會被編譯，然后被構建為可部署的版本，它們通常被稱為神器(artifacts 或工件)或包。
上述步驟是各種開發(fā)流程的簡化步驟，它們省略了一些對于分批部署的策略考慮。
在具體考慮該流程每個階段的責任時，我們很自然地會想到如下兩個關鍵問題：
- 在***步中，我們如何確保開發(fā)人員的變更集能夠與現(xiàn)有的項目相集成?任何變更不應破壞現(xiàn)有代碼庫，如：不可引入新的問題。
如何界定變更具有良好的代碼質量，我們在應用環(huán)境該如何判定呢?特別是那些與人身安全相關的醫(yī)療應用。
- 誰(或是什么工具)對于上述第二、三步進行管控和保障?
在 CI 的開發(fā)模式中，我們需要通過自動化來回答上述問題。例如：針對第二、三步，我們需要驗證開發(fā)人員的變更，是否能被主代碼庫所接受和集成，以及整個團隊能否成功完成項目的構建，并運行相關的測試。
因此，在一個理想的 CI 環(huán)境中，每一段代碼都是在開發(fā)的過程中被集成的。對于此類企業(yè)而言，每一天(更有甚者是每次提交)都會發(fā)生好幾次的代碼集成。
什么是持續(xù)交付和持續(xù)部署?
持續(xù)交付和持續(xù)部署將自動化帶到了一個新的高度，它們能夠將您最近一次提交的內容進行自動分發(fā)，并成為整個軟件的新版本。
持續(xù)交付：是指構建神器，并做好部署準備的過程。一般需要人工來判定是否的確需要部署。
持續(xù)部署：意味著所有流程都是自動的。即：在無人為干預的情況下，通過單次提交來觸發(fā)自動管道，并最終將您的應用生產(chǎn)環(huán)境更新為***版本的過程。
雖然有許多公司已經(jīng)實現(xiàn)了持續(xù)交付，但是很少做到持續(xù)部署的。而且，持續(xù)部署是有風險的，因為任何人都有可能通過一個簡單的提交，就將 Bug 引入了生產(chǎn)環(huán)境。因此，我們需要通過流程來降低這種風險。
持續(xù)集成的好處
以往在非 CI 環(huán)境中，人們針對軟件項目，主要采用的是主干-分支(trunk-branch)式的版本控制。
開發(fā)人員長期在分支上開發(fā)各種功能。隨著時間的推移，他們在將自己的變更與其他開發(fā)人員集成時，往往會不知不覺地讓分支偏離了主干。
因此，為了確保所有的變更都能兼容生產(chǎn)系統(tǒng)，開發(fā)人員往往在整合分支功能的過程中苦不堪言，他們甚至創(chuàng)造了短語--“整合地獄(integration hell)”。
如今，CI 的工作流程正好能夠通過輕松、例行的集成方式，解決這個問題。
持續(xù)集成不但能夠節(jié)省開發(fā)人員的時間，避免他們手動整合的各種變更，還能提高軟件的可靠性。
開發(fā)團隊能夠籍此更有信心地通過編寫代碼(和相關的測試)，來增加新的功能，并向用戶自動推送發(fā)布。
持續(xù)集成實踐的前提
我們在采用持續(xù)集成的工作流程中，會涉及到如下必備的條件：
- 版本控制系統(tǒng)工具
- 構建工具
- 神器庫管理器(Artifacts Repository Manager)
持續(xù)集成依賴于版本控制系統(tǒng)
持續(xù)集成最重要的前提條件是對其代碼庫的版本控制，即：對于代碼庫的每一項變更，都必須被安全地存放到專有的版本控制系統(tǒng)(Concurrent Versions System，VCS)中。
一旦實現(xiàn)了代碼版本控制，我們就能用 CI 工具來進行訪問。在市場上盛行的 VCS 工具中，Git 是***的一款，我們下面來簡單介紹一下。
Git 最初是由 Linus Torvalds 為 Linux 內核所創(chuàng)建的，其主要特征包括：
- 支持非線性開發(fā)：Git 的分支(與合并)是在開發(fā)者的電腦上進行的。
- 分布式開發(fā)：每個開發(fā)人員都擁有整個存儲庫歷史記錄的本地拷貝。
- 對大型項目的有效處置：在處置大型代碼庫時，Git 能夠快速地執(zhí)行性能測試。
- 用戶身份認證：通過加密和簽名，來實現(xiàn)對提交人的驗明正身。
- 對代碼歷史的加密認證：正如在區(qū)塊鏈中，某個特定提交的 ID 取決于其前面的內容那樣，在 Git 中改變歷史代碼后，其提交 ID 也會跟著變化。
- 垃圾收集：無用的對象會被自動進行垃圾收集。如果空間不足，您也能顯式地調用垃圾收集來清理某個 Git 存儲庫。
用構建工具實現(xiàn)持續(xù)集成
構建工具能夠通過處理應用的源代碼，自動生成所需的軟件。一般而言，軟件工具的構建步驟取決于所選用的技術棧。
下面是一個 Java 應用程序構建步驟的示例：
- 如有需要，根據(jù)現(xiàn)有配置生成 .java 的文件。
- 將源代碼(.java 文件)編譯成字節(jié)碼(.class 文件)。
- 將測試代碼編譯成字節(jié)碼。
- 執(zhí)行各種單元測試。
- 按需進行集成測試。
- 將多個 .class 文件打包成一個 JAR 文檔。
- 按需將 JAR 文件存入神器庫管理器。
- 按需在控制系統(tǒng)版本中，對代碼做相應的標記。
對于上述例子，我們一般可用到如下的構建工具：
- Ant，針對 Java 技術的、且基于 XML 的跨平臺生成工具。
- Maven，是一種基于 XML 的廣泛聲明，它偏向于將約定優(yōu)于配置。
上述兩種典型的構建工具和流程，都具有重復構建的能力。這意味著只要是一組相同的源代碼，就應該能產(chǎn)生相同的一組神器輸出。
例如：對于相同代碼庫，無論是開發(fā)人員用筆記本電腦進行構建、還是 CI 系統(tǒng)構建，它們都應當產(chǎn)生相同的結果。
這樣會帶來如下的好處：
- 首先，通過消除在開發(fā)人員筆記本和數(shù)據(jù)中心服務器上運行代碼的差異性，進而降低在開發(fā)環(huán)境和生產(chǎn)環(huán)境中運行可能產(chǎn)生的異常問題。您也不會再聽到“它在我的電腦上運行的時候是好好的啊!”之類的言論。
- 其次，如果在 CI 系統(tǒng)中通過了測試，那么由于運行的代碼是相同的，它就能***限度地減少生產(chǎn)環(huán)境的中斷。
- ***，如果它們能夠以一種一致的、且可重復的方式構建的話，必定能提高神器的緩存效率，并能在不同階段共享二進制文件。
用神器庫管理器存儲各種持續(xù)集成過程的結果
正如源代碼需要被存儲在 VCS 中那樣，那些能夠產(chǎn)生構建過程的神器同樣需要被存儲在某個遠程文件系統(tǒng)中。
因此，我們可以使用專用的軟件，如二進制庫管理器(Binary Repository Manager)來管理神器。
維基百科是這樣定義二進制庫管理器的：它是一種軟件工具，旨在優(yōu)化下載和存儲那些在軟件開發(fā)的過程中所產(chǎn)生和使用到的二進制文件。它被組織用來集中式管理二進制的神器，從而克服多種二進制神器類型的復雜性，進而減少整個工作流之間的依賴關系。
可見，神器庫管理器具有如下主要功能：
- 緩存：由于庫管理器會被安裝在公司系統(tǒng)內，因此開發(fā)人員訪問它的速度比遠程訪問更快。
- 通過被設為代理服務器，它能夠緩存那些已下載的第三方神器，并加快對其訪問。
- 保存策略：庫管理器能夠自動清空閑置的神器，以收回寶貴的空間。
- 高可用性：由于庫管理器的掉線勢必會影響到企業(yè)項目構建的平穩(wěn)運行，因此我們可以把庫管理器組建成為群集，以便開發(fā)人員和 CI 工具隨時訪問。
用戶限制：***庫管理器能夠通過限制訪問權限，來為神器制定對應的用戶和組。
從開發(fā)到真實構建的簡單 CI 工作流
由于不同企業(yè)所使用的軟件、堆棧和用例有所不同，他們的 CI 工作流也可能各式各樣。
下面讓我們以一個簡單工作流為例，探討一下從開始研發(fā)到真正構建的自動化過程。
分支
我們一般有兩種從代碼庫獲取***拷貝的可能：
- 如果是***訪問的話，您需要進行“下載”。即：使用 git clone 命令，拷貝 Git 的遠程代碼庫到本地。
- 如果代碼庫已經(jīng)存在本地，您可以使用類似 git pull 的命令，將其與遠程存儲庫同步。
在版本控制系統(tǒng)中，有一個專有的分支可以指向軟件的***、且穩(wěn)定的版本(通常被稱為 master 版本)，這個版本正是我們需要發(fā)布到生產(chǎn)環(huán)境中的。
為了保留這個黃金標準(gold standard)版本，并避免出現(xiàn)各種的 Bug，我們不應該對它進行直接的寫操作。因此，每一次開發(fā)都應該從 master 版本里創(chuàng)建一個專有的分支開始。
同時，為了保持代碼的井井有條，我們還應當盡可能地對分支采取有命名規(guī)則的方案，其中常用到的前綴包括：develop、feature、release 和 hotfix 等。
測試
根據(jù)具體情況的不同，測試方案既可以被事先編寫，即：測試驅動型設計(Test-Driven Design);也可以在代碼完成后再編寫。無論是之前還是之后，我們都需要通過回歸測試來保證代碼的穩(wěn)定運行。
測試代碼的覆蓋率也應當視具體情況而定：對于涉及到人類生命的軟件，如飛機導航或手術輔助，其每一行代碼都需要被檢查(甚至要二重、或三重檢查)。而在其他情況下，測試的覆蓋率就不一定那么高了。
拉式請求(Pull Request)
記住，不要對 master 進行直接變更，而應該在某個專門的分支上進行。一旦開發(fā)完成，團隊成員就應該考慮是否要將變更合并到主分支上。
因此，拉式請求的目標就是：您去詢問自己的團隊是否將變更接納成為黃金標準，并且開放您的補丁包供他人評審。
而一旦拉式請求被開啟，分支就會自動使用項目的構建工具進行構建，并確保變更不會破壞我們的主分支。
質量保證
一般情況下，我們還會伴隨進行其他步驟，包括：對提交的代碼進行安全性、代碼質量、文檔標準等方面的自動審核。
說到代碼質量，就不得不提及該領域的老牌開源平臺 SonarQube(https://www.sonarqube.org/)。
SonarQube 能夠與各大主流 CI 工具相集成，對某個代碼庫執(zhí)行配置檢查。
下面是對于持續(xù)檢查(Continuous Inspection)的詮釋：SonarQube 不僅能夠展示某個應用程序的健康狀態(tài)，還能突顯各種新引入的問題。通過質量門(Quality Gate)，您可以修復漏洞，進而系統(tǒng)地提高代碼的質量。
構建
拉式請求一旦啟動，自動構建就會通過各種 CI 工具，自動進行編譯、測試、打包等步驟。
當然，如果一個(或多個)自動構建步驟出現(xiàn)失敗，我們則認為整個構建失敗。
在大多數(shù) CI 工具中，失敗的構建會以紅色顯示，而綠色則表示已經(jīng)順利通過的構建。
因此，您可能會聽到有人將已通過的構建稱為“綠色構建(green build)”。相反，如果構建失敗，則無論是什么原因，都會返回給處于拉式請求之初的開發(fā)人員予以修復。
代碼審查
雖然諸如 SonarQube 之類的工具可以檢測一些簡單的錯誤模式，如雙重檢查鎖定(Double Checked Locking，https://fr.wikipedia.org/wiki/Double-checked_locking)，但是更復雜的 Bug 還是需人工進行代碼審查的。
因此，將代碼變更合并到 master 之前的***一步便是：團隊成員的手動代碼審查(這正是拉式請求的意義所在)。
不同的開發(fā)人員會有不同的代碼審查方式。但是我建議您從基礎方面做起，例如，您可以參考：代碼審查到底要查什么?(https://leanpub.com/whattolookforinacodereview)。
標記、版本控制和存儲構建神器
代碼變更終于在這個階段以 hot-fix 的形式被合入 master 并發(fā)布了。而 CI 工具也會再進行一次構建的重放，以確保萬無一失。
首先，VCS 需要對版本打上相應的版本標簽。雖然在企業(yè)實際開發(fā)過程中，大家常會以某個山名、湖名、甚至是蛋糕名字，來增加創(chuàng)意性，例如：Ubuntu 的“Placid Pangolin”和安卓的“Oreo”。
但是從原理上說，軟件開發(fā)者應該采用一套標準的版本控制方案和命名規(guī)則(如使用數(shù)字編號)，通過遵循規(guī)范的語義版本，來區(qū)分和定義 major、minor 和 bugfix 版本。如你想了解更多信息，請參見 semver.org。
其次，通過構建所產(chǎn)生的神器應當被存儲到神器庫管理器之中。籍此，當出現(xiàn)異常情況需要執(zhí)行“回滾”操作時，您可以直接使用以前的工作版本，而無需對源代碼進行重新構建。
持續(xù)集成工具概述
隨著持續(xù)集成的廣泛應用，與之相關工具的生態(tài)系統(tǒng)也日趨成熟。下面我們來討論一些目前最為流行和常用的 CI/CD 系統(tǒng)。
它們的用戶既有完全依賴云服務運營的初創(chuàng)企業(yè)，也有在自己內部使用復雜 CI 平臺的大型組織。
Jenkins
Jenkins 是持續(xù)集成領域最老牌、且最被廣泛應用的開源項目之一。該工具利弊共存：多年來，其核心架構已經(jīng)歷了從小型部署到大公司生產(chǎn)環(huán)境的多種“實戰(zhàn)”檢驗。
另外，Jenkins 擁有一個“充滿活力”的在線用戶社區(qū)，能夠幫助您為各種問題尋求解決方案。
當然，它的內部抽象機制可能對于一些具有大型遺留代碼庫、和向后兼容性的需求有些過時，并可能會經(jīng)常出現(xiàn)跨不同用戶場景的泄漏現(xiàn)象。
此外，盡管 Jenkins 擁有著廣泛的插件生態(tài)系統(tǒng)，并提供了許多時髦的功能，但是由于這些插件通常是由社區(qū)所開發(fā)，因此質量和可靠性參差不齊。
近年來，Jenkins 常被描述為持續(xù)集成的工作流，即：管道(pipelines，請參見：https://jenkins.io/doc/book/pipeline/)。
開發(fā)人員能夠用它來聲明和描述與構建和部署有關的過程。而且，Jenkins 還允許您創(chuàng)建一些能夠在不同項目中，通過重用來規(guī)范和簡化通用流程的不同模塊。
總之，Jenkins 擁有悠久的開發(fā)和應用歷史，以及龐大且活躍的社區(qū)支持，同時它能夠被高度定制?？梢哉f，開發(fā)人員一旦掌握了它，就遠離了失業(yè)的風險。
Travis CI
Travis CI 與 Jenkins 幾乎處于同樣的地位。雖然它有著許多開源的組件，但是如果缺少了企業(yè)賬號，您將無法采用自托管的模式。不過，使用任何開源項目來運行 Travis 都是免費的。
Travis 運行的每個任務都必須被包含在 travis.yml 中，而該文件也需要被載入到您的代碼段中。這就意味著您可以從一個存儲庫的不同分支上運行不同的任務。
Travis 的宗旨是簡單化。您可以從 GitHub 托管庫中直接工作，并在許多應用中維護一個通用的服務庫。
當然，如果您沒有用到 GitHub、或是需要有更多的控制，那么 Travis 可能就不適合您了。
Travis 的一個實用功能是能夠在多種操作系統(tǒng)上運行，即：您可以在不同的目標系統(tǒng)上測試自己的代碼，而無需維護各種虛擬機或鏡像。
GitLab 持續(xù)集成/持續(xù)交付
GitLab 源于一項源碼托管的服務。它與 GitHub 有類似之處，同時也提供一個開源的版本。
不過，與 GitHub 的不同之處在于：GitLab 包括一個內置于平臺之中的，被稱為 AutoDevOps 的高級 CI/CD 實現(xiàn)。
對于已經(jīng)使用 GitLab 來存儲源代碼的用戶來說，這種緊密集成是 GitLab 在 CI/CD 上能夠提供的最實用的功能之一。
您可以通過在源代碼庫的根目錄上添加 .gitlab-ci.yml 配置文件，來啟用它。當然，您也可以將 GitLab 的 CI/CD 與 GitHub 的存儲庫相集成。
Bamboo
Bamboo 是 Atlassian 公司的持續(xù)集成/持續(xù)交付產(chǎn)品。該公司的另一個老牌軟件產(chǎn)品是 JIRA —一種 Bug 跟蹤軟件。
Bamboo 的主要優(yōu)勢在于：它能與那些已經(jīng)在自己的系統(tǒng)中使用的其他 Atlassian 產(chǎn)品(如 JIRA 和 Bitbucket)緊密集成。
不過，相比其擁有大量插件市場的優(yōu)勢，Bamboo 的用戶社區(qū)規(guī)模不算大，因此用戶需要更加依賴于 Atlassian 本身的支持。
CircleCI
CircleCI 是一種在線服務，它提供了強大的 CI 平臺，當然它也提供主機托管版本。
CircleCI 平臺主要服務于容器，并能為測試提供快速的擴展(spin-up)。它的工作流功能，允許用戶為復雜的項目自定義 CI 和 CD 的作業(yè)序列。
CircleCI 的主要優(yōu)點是：它是一個全托管式的 CI 解決方案，因此減少了最終用戶花費在系統(tǒng)維護上的時間。
結論
僅靠選對了持續(xù)集成的***實踐和工具，我們是無法保證能夠將自己的組織帶入 CI 正軌的。
對于許多傳統(tǒng)的軟件企業(yè)而言，他們還需要整個軟件開發(fā)團隊在協(xié)作方式上的轉變。
為了能夠成功地將一整套變更集整合到代碼庫中，團隊成員應當事先約定好各種工作模式和規(guī)范，并能夠堅持執(zhí)行。
要想實現(xiàn)可靠的構建步驟，團隊成員有時候要對生產(chǎn)環(huán)境中的各種問題進行嚴格的重構和持續(xù)的部署，進而拓寬整個團隊在設計上的視野。
綜上所述，持續(xù)集成能夠給軟件組織帶來的好處是不言而喻的。如今它已經(jīng)成為了新的軟件規(guī)范，企業(yè)必將通過不斷的 CI 實踐，以加速項目的交付和質量的提升。
【原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為.com】
本文標題：僅需一篇，妥妥吃透“持續(xù)集成”
文章URL：http://www.dlmjj.cn/article/cdpgpoh.html
