[[350857]]

 GitLab CI/CD 是一個內(nèi)置在GitLab中的工具，用于通過持續(xù)方法進行軟件開發(fā)：

•  Continuous Integration (CI)  持續(xù)集成
•  Continuous Delivery (CD)     持續(xù)交付
•  Continuous Deployment (CD)   持續(xù)部署

持續(xù)集成的工作原理是將小的代碼塊推送到Git倉庫中托管的應用程序代碼庫中，并且每次推送時，都要運行一系列腳本來構建、測試和驗證代碼更改，然后再將其合并到主分支中。

持續(xù)交付和部署相當于更進一步的CI，可以在每次推送到倉庫默認分支的同時將應用程序部署到生產(chǎn)環(huán)境。

這些方法使得可以在開發(fā)周期的早期發(fā)現(xiàn)bugs和errors，從而確保部署到生產(chǎn)環(huán)境的所有代碼都符合為應用程序建立的代碼標準。

GitLab CI/CD 由一個名為 .gitlab-ci.yml 的文件進行配置，改文件位于倉庫的根目錄下。文件中指定的腳本由GitLab Runner執(zhí)行。

1. GitLab CI/CD 介紹

軟件開發(fā)的持續(xù)方法基于自動執(zhí)行腳本，以最大程度地減少在開發(fā)應用程序時引入錯誤的機會。從開發(fā)新代碼到部署新代碼，他們幾乎不需要人工干預，甚至根本不需要干預。

它涉及到在每次小的迭代中就不斷地構建、測試和部署代碼更改，從而減少了基于已經(jīng)存在bug或失敗的先前版本開發(fā)新代碼的機會。

Continuous Integration（持續(xù)集成）

假設一個應用程序，其代碼存儲在GitLab的Git倉庫中。開發(fā)人員每天都要多次推送代碼更改。對于每次向倉庫的推送，你都可以創(chuàng)建一組腳本來自動構建和測試你的應用程序，從而減少了向應用程序引入錯誤的機會。這種做法稱為持續(xù)集成，對于提交給應用程序（甚至是開發(fā)分支）的每項更改，它都會自動連續(xù)進行構建和測試，以確保所引入的更改通過你為應用程序建立的所有測試，準則和代碼合規(guī)性標準。

Continuous Delivery（持續(xù)交付）

持續(xù)交付是超越持續(xù)集成的更進一步的操作。應用程序不僅會在推送到代碼庫的每次代碼更改時進行構建和測試，而且，盡管部署是手動觸發(fā)的，但作為一個附加步驟，它也可以連續(xù)部署。此方法可確保自動檢查代碼，但需要人工干預才能從策略上手動觸發(fā)以必輸此次變更。

Continuous Deployment（持續(xù)部署）

與持續(xù)交付類似，但不同之處在于，你無需將其手動部署，而是將其設置為自動部署。完全不需要人工干預即可部署你的應用程序。

1.1. GitLab CI/CD 是如何工作的

為了使用GitLab CI/CD，你需要一個托管在GitLab上的應用程序代碼庫，并且在根目錄中的.gitlab-ci.yml文件中指定構建、測試和部署的腳本。

在這個文件中，你可以定義要運行的腳本，定義包含的依賴項，選擇要按順序運行的命令和要并行運行的命令，定義要在何處部署應用程序，以及指定是否 要自動運行腳本或手動觸發(fā)腳本。

為了可視化處理過程，假設添加到配置文件中的所有腳本與在計算機的終端上運行的命令相同。

一旦你已經(jīng)添加了.gitlab-ci.yml到倉庫中，GitLab將檢測到該文件，并使用名為GitLab Runner的工具運行你的腳本。該工具的操作與終端類似。

這些腳本被分組到jobs，它們共同組成一個pipeline。一個最簡單的.gitlab-ci.yml文件可能是這樣的： 

before_script:   
  - apt-get install rubygems ruby-dev -y   
run-test:   
  script:   
    - ruby --version 6 

before_script屬性將在運行任何內(nèi)容之前為你的應用安裝依賴，一個名為run-test的job（作業(yè)）將打印當前系統(tǒng)的Ruby版本。二者共同構成了在每次推送到倉庫的任何分支時都會被觸發(fā)的pipeline（管道）。

GitLab CI/CD不僅可以執(zhí)行你設置的job，還可以顯示執(zhí)行期間發(fā)生的情況，正如你在終端看到的那樣：

為你的應用創(chuàng)建策略，GitLab會根據(jù)你的定義來運行pipeline。你的管道狀態(tài)也會由GitLab顯示：

最后，如果出現(xiàn)任何問題，可以輕松地回滾所有更改：

1.2. 基本 CI/CD 工作流程

一旦你將提交推送到遠程倉庫的分支上，那么你為該項目設置的CI/CD管道將會被觸發(fā)。GitLab CI/CD 通過這樣做：

•  運行自動化腳本（串行或并行） 代碼Review并獲得批準
  •  構建并測試你的應用
  •  就像在你本機中看到的那樣，使用Review Apps預覽每個合并請求的更改
•  代碼Review并獲得批準
•  合并feature分支到默認分支，同時自動將此次更改部署到生產(chǎn)環(huán)境
•  如果出現(xiàn)問題，可以輕松回滾
•  通過GitLab UI所有的步驟都是可視化的

1.3. 深入了解CI/CD基本工作流程

如果我們深入研究基本工作流程，則可以在DevOps生命周期的每個階段看到GitLab中可用的功能，如下圖所示：

1.Verify

•  通過持續(xù)集成自動構建和測試你的應用程序
•  使用GitLab代碼質量（GitLab Code Quality）分析你的源代碼質量
•  通過瀏覽器性能測試（Browser Performance Testing）確定代碼更改對性能的影響
•  執(zhí)行一系列測試，比如Container Scanning , Dependency Scanning , JUnit tests
•  用Review Apps部署更改，以預覽每個分支上的應用程序更改

2.Package

•  用Container Registry存儲Docker鏡像
•  用NPM Registry存儲NPM包
•  用Maven Repository存儲Maven artifacts
•  用Conan Repository存儲Conan包

3.Release

•  持續(xù)部署，自動將你的應用程序部署到生產(chǎn)環(huán)境
•  持續(xù)交付，手動點擊以將你的應用程序部署到生產(chǎn)環(huán)境
•  用GitLab Pages部署靜態(tài)網(wǎng)站
•  僅將功能部署到一個Pod上，并讓一定比例的用戶群通過Canary Deployments訪問臨時部署的功能（PS：即灰度發(fā)布）
•  在Feature Flags之后部署功能
•  用GitLab Releases將發(fā)布說明添加到任意Git tag
•  使用Deploy Boards查看在Kubernetes上運行的每個CI環(huán)境的當前運行狀況和狀態(tài)
•  使用Auto Deploy將應用程序部署到Kubernetes集群中的生產(chǎn)環(huán)境

使用GitLab CI/CD，還可以：

•  通過Auto DevOps輕松設置應用的整個生命周期
•  將應用程序部署到不同的環(huán)境
•  安裝你自己的GitLab Runner
•  Schedule pipelines
•  使用安全測試報告（Security Test reports）檢查應用程序漏洞

2. GitLab CI/CD 快速開始

.gitlab-ci.yml文件告訴GitLab Runner要做什么。一個簡單的管道通常包括三個階段：build、test、deploy

管道在 CI/CD > Pipelines 頁面

2.1. 創(chuàng)建一個 .gitlab-ci.yml 文件

通過配置.gitlab-ci.yml文件來告訴CI要對你的項目做什么。它位于倉庫的根目錄下。

倉庫一旦收到任何推送，GitLab將立即查找.gitlab-ci.yml文件，并根據(jù)文件的內(nèi)容在Runner上啟動作業(yè)。

下面是一個Ruby項目配置例子： 

image: "ruby:2.5"  
 before_script:  
   - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs  
   - ruby -v  
   - which ruby  
   - gem install bundler --no-document  
   - bundle install --jobs $(nproc)  "${FLAGS[@]}"  
 rspec:  
   script:  
     - bundle exec rspec  
 rubocop:  
   script:  
     - bundle exec rubocop 

上面的例子中，定義里兩個作業(yè)，分別是 rspec 和 rubocop，在每個作業(yè)開始執(zhí)行前，要先執(zhí)行before_script下的命令

2.2. 推送 .gitlab-ci.yml 到 GitLab 

git add .gitlab-ci.yml  
git commit -m "Add .gitlab-ci.yml"   
git push origin master 

2.3. 配置一個Runner

在GitLab中，Runner運行你定義在.gitlab-ci.yml中的作業(yè)（job）

一個Runner可以是一個虛擬機、物理機、docker容器，或者一個容器集群

GitLab與Runner之間通過API進行通信，因此只需要Runner所在的機器有網(wǎng)絡并且可以訪問GitLab服務器即可

你可以去 Settings ➔ CI/CD 看是否已經(jīng)有Runner關聯(lián)到你的項目，設置Runner簡單又直接

2.4. 查看 pipeline 和 jobs的狀態(tài)

在成功配置Runner以后，你應該可以看到你最近的提交的狀態(tài)

為了查看所有jobs，你可以去 Pipelines ➔ Jobs 頁面

通過點擊作業(yè)的狀態(tài)，你可以看到作業(yè)運行的日志

回顧一下：

•  1、首先，定義.gitlab-ci.yml文件。在這個文件中就定義了要執(zhí)行的job和命令
•  2、接著，將文件推送至遠程倉庫
•  3、最后，配置Runner，用于運行job

3. Auto DevOps

Auto DevOps 提供了預定義的CI/CD配置，使你可以自動檢測，構建，測試，部署和監(jiān)視應用程序。借助CI/CD最佳實踐和工具，Auto DevOps旨在簡化成熟和現(xiàn)代軟件開發(fā)生命周期的設置和執(zhí)行。

借助Auto DevOps，軟件開發(fā)過程的設置變得更加容易，因為每個項目都可以使用最少的配置來完成從驗證到監(jiān)視的完整工作流程。只需推送你的代碼，GitLab就會處理其他所有事情。這使得啟動新項目更加容易，并使整個公司的應用程序設置方式保持一致。

下面這個例子展示了如何使用Auto DevOps將GitLab.com上托管的項目部署到Google Kubernetes Engine

示例中會使用GitLab原生的Kubernetes集成，因此不需要再單獨手動創(chuàng)建Kubernetes集群

本例將創(chuàng)建并部署一個從GitLab模板創(chuàng)建的應用

3.1. 從GitLab模板創(chuàng)建項目

在創(chuàng)建Kubernetes集群并將其連接到GitLab項目之前，你需要一個Google Cloud Platform帳戶

下面使用GitLab的項目模板來創(chuàng)建一個新項目

給項目起一個名字，并確保它是公有的

3.2. 從GitLab模板創(chuàng)建Kubernetes集群

點擊 Add Kubernetes cluster 按鈕，或者 Operations > Kubernetes

安裝Helm, Ingress, 和 Prometheus

3.3. 啟用Auto DevOps (可選)

Auto DevOps 默認是啟用的。

導航欄 Settings > CI/CD > Auto DevOps

勾選 Default to Auto DevOps pipeline

最后選擇部署策略

一旦你已經(jīng)完成了以上所有的操作，那么一個新的 pipeline 將會被自動創(chuàng)建。為了查看pipeline，可以去 CI/CD > Pipelines

3.4. 部署應用

到目前為止，你應該看到管道正在運行，但是它到底在運行什么呢？

管道內(nèi)部分為4個階段，我們可以查看每個階段有幾個作業(yè)在運行，如下圖：

構建 -> 測試 -> 部署 -> 性能測試

現(xiàn)在，應用已經(jīng)成功部署，讓我們通過瀏覽器查看。

首先，導航到 Operations > Environments

在Environments中，可以看到部署的應用的詳細信息。在最右邊有三個按鈕，我們依次來看一下：

第一個圖標將打開在生產(chǎn)環(huán)境中部署的應用程序的URL。這是一個非常簡單的頁面，但重要的是它可以正常工作！

緊挨著第二個是一個帶小圖像的圖標，Prometheus將在其中收集有關Kubernetes集群以及應用程序如何影響它的數(shù)據(jù)（在內(nèi)存/ CPU使用率，延遲等方面）

第三個圖標是Web終端，它將在運行應用程序的容器內(nèi)打開終端會話。

4. Examples

使用GitLab CI/CD部署一個Spring Boot應用

示例 .gitlab-ci.yml 

image: java:8   
stages:  
  - build  
  - deploy  
before_script:  
  - chmod +x mvnw  
build:  
  stage: build  
  script: ./mvnw package 
   artifacts:  
    paths:  
      - target/demo-0.0.1-SNAPSHOT.jar  
production:  
  stage: deploy  
  script:  
  - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx  
  - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io 
   - ./cf push  
  only:  
  - master