鏈接：https://note./2018/11/cntlm-proxy/鏈接：https://www.cnblogs.com/cjsblog/p/12256843.html

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

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

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

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

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

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

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

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

GitLab CI/CD 介紹

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

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

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

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

• Continuous Deployment（持續(xù)部署）,，與持續(xù)交付類似,，但不同之處在于，你無需將其手動(dòng)部署,，而是將其設(shè)置為自動(dòng)部署,。完全不需要人工干預(yù)即可部署你的應(yīng)用程序。

GitLab CI/CD 是如何工作的

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

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

為了可視化處理過程，假設(shè)添加到配置文件中的所有腳本與在計(jì)算機(jī)的終端上運(yùn)行的命令相同,。

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

這些腳本被分組到 jobs，它們共同組成一個(gè) Pipeline,。一個(gè)最簡(jiǎn)單的 .gitlab-ci.yml 文件可能是這樣的：

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

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

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

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

基本 CI/CD 工作流程

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

• 運(yùn)行自動(dòng)化腳本（串行或并行） 代碼Review并獲得批準(zhǔn)

• 構(gòu)建并測(cè)試你的應(yīng)用

• 就像在你本機(jī)中看到的那樣，使用 Review Apps 預(yù)覽每個(gè)合并請(qǐng)求的更改

• 代碼 Review 并獲得批準(zhǔn)

• 合并 feature 分支到默認(rèn)分支,，同時(shí)自動(dòng)將此次更改部署到生產(chǎn)環(huán)境

• 如果出現(xiàn)問題,，可以輕松回滾

通過 GitLab UI 所有的步驟都是可視化的 。

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

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

Verify：

• 通過持續(xù)集成自動(dòng)構(gòu)建和測(cè)試你的應(yīng)用程序

• 使用 GitLab 代碼質(zhì)量（GitLab Code Quality）分析你的源代碼質(zhì)量

• 通過瀏覽器性能測(cè)試（Browser Performance Testing）確定代碼更改對(duì)性能的影響

• 執(zhí)行一系列測(cè)試，比如 Container Scanning,，Dependency Scanning,，JUnit tests

• 用 Review Apps 部署更改，以預(yù)覽每個(gè)分支上的應(yīng)用程序更改

Package：

• 用 Container Registry 存儲(chǔ) Docker 鏡像

• 用 NPM Registry 存儲(chǔ) NPM 包

• 用 Maven Repository 存儲(chǔ) Maven artifacts

• 用 Conan Repository 存儲(chǔ) Conan 包

Release：

• 持續(xù)部署,，自動(dòng)將你的應(yīng)用程序部署到生產(chǎn)環(huán)境

• 持續(xù)交付,，手動(dòng)點(diǎn)擊以將你的應(yīng)用程序部署到生產(chǎn)環(huán)境

• 用 GitLab Pages 部署靜態(tài)網(wǎng)站

• 僅將功能部署到一個(gè) Pod 上，并讓一定比例的用戶群通過 Canary Deployments 訪問臨時(shí)部署的功能（PS：即灰度發(fā)布）

• 在 Feature Flags 之后部署功能

• 用 GitLab Releases 將發(fā)布說明添加到任意 Git tag

• 使用 Deploy Boards 查看在 Kubernetes 上運(yùn)行的每個(gè) CI 環(huán)境的當(dāng)前運(yùn)行狀況和狀態(tài)

• 使用 Auto Deploy 將應(yīng)用程序部署到 Kubernetes 集群中的生產(chǎn)環(huán)境

使用 GitLab CI/CD,，還可以：

• 通過 Auto DevOps 輕松設(shè)置應(yīng)用的整個(gè)生命周期

• 將應(yīng)用程序部署到不同的環(huán)境

• 安裝你自己的 GitLab Runner

• Schedule pipelines

• 使用安全測(cè)試報(bào)告（Security Test reports）檢查應(yīng)用程序漏洞

GitLab CI/CD 快速開始

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

管道在 CI/CD > Pipelines 頁面,。

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

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

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

下面是一個(gè) Ruby 項(xiàng)目配置例子：

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

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

推送 .gitlab-ci.yml 到 GitLab

配置一個(gè) Runner

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

一個(gè) Runner 可以是一個(gè)虛擬機(jī)、物理機(jī),、Docker 容器,，或者一個(gè)容器集群。

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

你可以去 Settings ? CI/CD 看是否已經(jīng)有 Runner 關(guān)聯(lián)到你的項(xiàng)目，設(shè)置 Runner 簡(jiǎn)單又直接,。

查看 Pipeline 和 jobs 的狀態(tài)

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

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

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

回顧一下：

• 首先,，定義 .gitlab-ci.yml 文件,。在這個(gè)文件中就定義了要執(zhí)行的 job 和命令

• 接著，將文件推送至遠(yuǎn)程倉庫

• 最后,，配置 Runner,，用于運(yùn)行 job

Auto DevOps

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

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

下面這個(gè)例子展示了如何使用 Auto DevOps 將 GitLab.com 上托管的項(xiàng)目部署到 Google Kubernetes Engine。

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

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

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

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

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

給項(xiàng)目起一個(gè)名字,，并確保它是公有的,。

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

點(diǎn)擊 Add Kubernetes cluster 按鈕，或者 Operations > Kubernetes,。

安裝 Helm,，Ingress 和 Prometheus。

啟用 Auto DevOps（可選）

Auto DevOps 默認(rèn)是啟用的,。

導(dǎo)航欄 Settings > CI/CD > Auto DevOps,。

勾選 Default to Auto DevOps pipeline,。

最后選擇部署策略。

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

部署應(yīng)用

到目前為止,，你應(yīng)該看到管道正在運(yùn)行，但是它到底在運(yùn)行什么呢,？

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

構(gòu)建 -> 測(cè)試 -> 部署 -> 性能測(cè)試

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

首先,，導(dǎo)航到 Operations > Environments,。

在 Environments 中，可以看到部署的應(yīng)用的詳細(xì)信息,。在最右邊有三個(gè)按鈕,，我們依次來看一下：

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

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

第三個(gè)圖標(biāo)是Web終端，它將在運(yùn)行應(yīng)用程序的容器內(nèi)打開終端會(huì)話,。

Examples

使用 GitLab CI/CD 部署一個(gè) Spring Boot 應(yīng)用,。

示例 .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./stable\?release=linux64-binary\&source=github' | tar zx  
   - ./cf login -u \$CF\_USERNAME -p \$CF\_PASSWORD -a api.run.  
   - ./cf push  
   only:  
   - master