用 GitLab 作 CI/CD 是什麼感受，太強了

GitLab CI/CD 是一個內置在 GitLab 中的工具，用於經過持續方法進行軟件開發：

• Continuous Integration（CI）：持續集成

• Continuous Delivery（CD）：持續交付

• Continuous Deployment（CD）：持續部署

持續集成的工做原理是將小的代碼塊推送到 Git 倉庫中託管的應用程序代碼庫中，而且每次推送時，都要運行一系列腳原本構建、測試和驗證代碼更改，而後再將其合併到主分支中。

持續交付和部署至關於更進一步的 CI，能夠在每次推送到倉庫默認分支的同時將應用程序部署到生產環境。

這些方法使得能夠在開發週期的早期發現 bugs 和 errors，從而確保部署到生產環境的全部代碼都符合爲應用程序創建的代碼標準。

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

GitLab CI/CD 介紹

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

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

• Continuous Integration（持續集成），假設一個應用程序，其代碼存儲在 GitLab 的 Git 倉庫中。開發人員天天都要屢次推送代碼更改。對於每次向倉庫的推送，你均可以建立一組腳原本自動構建和測試你的應用程序，從而減小了嚮應用程序引入錯誤的機會。這種作法稱爲持續集成，對於提交給應用程序（甚至是開發分支）的每項更改，它都會自動連續進行構建和測試，以確保所引入的更改經過你爲應用程序創建的全部測試，準則和代碼合規性標準。

• Continuous Delivery（持續交付），持續交付是超越持續集成的更進一步的操做。應用程序不只會在推送到代碼庫的每次代碼更改時進行構建和測試，並且，儘管部署是手動觸發的，但做爲一個附加步驟，它也能夠連續部署。此方法可確保自動檢查代碼，但須要人工干預才能從策略上手動觸發以必輸這次變動。

• Continuous Deployment（持續部署），與持續交付相似，但不一樣之處在於，你無需將其手動部署，而是將其設置爲自動部署。徹底不須要人工干預便可部署你的應用程序。

GitLab CI/CD 是如何工做的

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

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

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

一旦你已經添加了.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 屬性將在運行任何內容以前爲你的應用安裝依賴，一個名爲 run-test 的 job（做業）將打印當前系統的 Ruby 版本。兩者共同構成了在每次推送到倉庫的任何分支時都會被觸發的 Pipeline（管道）。

GitLab CI/CD 不只能夠執行你設置的 job，還能夠顯示執行期間發生的狀況，正如你在終端看到的那樣：

爲你的應用建立策略，GitLab 會根據你的定義來運行 Pipeline。你的管道狀態也會由 GitLab 顯示：

[外鏈圖片轉存中...(img-9vXw94DB-1610462909494)]

最後，若是出現任何問題，能夠輕鬆地回滾全部更改：

基本 CI/CD 工做流程

一旦你將提交推送到遠程倉庫的分支上，那麼你爲該項目設置的 CI/CD 管道將會被觸發。GitLab CI/CD 經過這樣作：

• 運行自動化腳本（串行或並行） 代碼Review並得到批准

  • 構建並測試你的應用

  • 就像在你本機中看到的那樣，使用 Review Apps 預覽每一個合併請求的更改

• 代碼 Review 並得到批准

• 合併 feature 分支到默認分支，同時自動將這次更改部署到生產環境

• 若是出現問題，能夠輕鬆回滾

經過 GitLab UI 全部的步驟都是可視化的 。

深刻了解CI/CD基本工做流程

若是咱們深刻研究基本工做流程，則能夠在 DevOps 生命週期的每一個階段看到 GitLab 中可用的功能，以下圖所示：

[外鏈圖片轉存中...(img-ynLeJIxi-1610462909523)]

Verify：

• 經過持續集成自動構建和測試你的應用程序

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

• 經過瀏覽器性能測試（Browser Performance Testing）肯定代碼更改對性能的影響

• 執行一系列測試，好比 Container Scanning，Dependency Scanning，JUnit tests

• 用 Review Apps 部署更改，以預覽每一個分支上的應用程序更改

Package：

• 用 Container Registry 存儲 Docker 鏡像

• 用 NPM Registry 存儲 NPM 包

• 用 Maven Repository 存儲 Maven artifacts

• 用 Conan Repository 存儲 Conan 包

Release：

• 持續部署，自動將你的應用程序部署到生產環境

• 持續交付，手動點擊以將你的應用程序部署到生產環境

• 用 GitLab Pages 部署靜態網站

• 僅將功能部署到一個 Pod 上，並讓必定比例的用戶羣經過 Canary Deployments 訪問臨時部署的功能（PS：即灰度發佈）

• 在 Feature Flags 以後部署功能

• 用 GitLab Releases 將發佈說明添加到任意 Git tag

• 使用 Deploy Boards 查看在 Kubernetes 上運行的每一個 CI 環境的當前運行情況和狀態

• 使用 Auto Deploy 將應用程序部署到 Kubernetes 集羣中的生產環境

使用 GitLab CI/CD，還能夠：

• 經過 Auto DevOps 輕鬆設置應用的整個生命週期

• 將應用程序部署到不一樣的環境

• 安裝你本身的 GitLab Runner

• Schedule pipelines

• 使用安全測試報告（Security Test reports）檢查應用程序漏洞

GitLab CI/CD 快速開始

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

管道在 CI/CD > Pipelines 頁面。

建立一個 .gitlab-ci.yml 文件

經過配置 .gitlab-ci.yml 文件來告訴 CI 要對你的項目作什麼。它位於倉庫的根目錄下。

倉庫一旦收到任何推送，GitLab 將當即查找 .gitlab-ci.yml 文件，並根據文件的內容在 Runner 上啓動做業。

下面是一個 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

上面的例子中，定義裏兩個做業，分別是 rspec 和 rubocop，在每一個做業開始執行前，要先執行 before_script 下的命令。

推送 .gitlab-ci.yml 到 GitLab

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

配置一個 Runner

在 GitLab 中，Runner 運行你定義在 .gitlab-ci.yml 中的做業（job）。

一個 Runner 能夠是一個虛擬機、物理機、Docker 容器，或者一個容器集羣。

GitLab 與 Runner 之間經過 API 進行通訊，所以只須要 Runner 所在的機器有網絡而且能夠訪問 GitLab 服務器便可。

你能夠去 Settings ➔ CI/CD 看是否已經有 Runner 關聯到你的項目，設置 Runner 簡單又直接。

[外鏈圖片轉存中...(img-rCvpV5DY-1610462909528)]

查看 Pipeline 和 jobs 的狀態

在成功配置 Runner 之後，你應該能夠看到你最近的提交的狀態。

爲了查看全部 jobs，你能夠去 Pipelines ➔ Jobs 頁面。

[外鏈圖片轉存中...(img-kD0oiY6J-1610462909535)]

經過點擊做業的狀態，你能夠看到做業運行的日誌。

回顧一下：

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

• 接着，將文件推送至遠程倉庫

• 最後，配置 Runner，用於運行 job

Auto DevOps

Auto DevOps 提供了預約義的 CI/CD 配置，使你能夠自動檢測，構建，測試，部署和監視應用程序。藉助 CI/CD 最佳實踐和工具，Auto DevOps 旨在簡化成熟和現代軟件開發生命週期的設置和執行。

藉助 Auto DevOps，軟件開發過程的設置變得更加容易，由於每一個項目均可以使用最少的配置來完成從驗證到監視的完整工做流程。只需推送你的代碼，GitLab 就會處理其餘全部事情。這使得啓動新項目更加容易，並使整個公司的應用程序設置方式保持一致。

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

示例中會使用 GitLab 原生的 Kubernetes 集成，所以不須要再單獨手動建立 Kubernetes 集羣。

本例將建立並部署一個從 GitLab 模板建立的應用。

從 GitLab 模板建立項目

在建立 Kubernetes 集羣並將其鏈接到 GitLab 項目以前，你須要一個 Google Cloud Platform 賬戶。

下面使用 GitLab 的項目模板來建立一個新項目。

[外鏈圖片轉存中...(img-HZO9EViH-1610462909544)]

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

[外鏈圖片轉存中...(img-vZI36UiI-1610462909548)]

從 GitLab 模板建立 Kubernetes 集羣

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

[外鏈圖片轉存中...(img-EdGVDGxG-1610462909562)]

[外鏈圖片轉存中...(img-bZeS2LFK-1610462909567)]

安裝 Helm，Ingress 和 Prometheus。

啓用 Auto DevOps（可選）

Auto DevOps 默認是啓用的。

導航欄 Settings > CI/CD > Auto DevOps。

勾選 Default to Auto DevOps pipeline。

最後選擇部署策略。

[外鏈圖片轉存中...(img-WE6BVbH6-1610462909578)]

一旦你已經完成了以上全部的操做，那麼一個新的 Pipeline 將會被自動建立。爲了查看 Pipeline，能夠去 CI/CD > Pipelines。

[外鏈圖片轉存中...(img-0qKffSoF-1610462909583)]

部署應用

到目前爲止，你應該看到管道正在運行，可是它到底在運行什麼呢？

管道內部分爲4個階段，咱們能夠查看每一個階段有幾個做業在運行，以下圖：

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

[外鏈圖片轉存中...(img-alHeune8-1610462909587)]

如今，應用已經成功部署，讓咱們經過瀏覽器查看。

首先，導航到 Operations > Environments。

[外鏈圖片轉存中...(img-nWpHQ1YO-1610462909591)]

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

第一個圖標將打開在生產環境中部署的應用程序的 URL。這是一個很是簡單的頁面，但重要的是它能夠正常工做！

緊挨着第二個是一個帶小圖像的圖標，Prometheus 將在其中收集有關 Kubernetes 集羣以及應用程序如何影響它的數據（在內存/ CPU使用率，延遲等方面）。

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

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

原文連接：http://www.javashuo.com/article/p-upfenqlj-dx.html