作者：廢物大師兄
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執行。
1. GitLab CI/CD 介紹
軟體開發的持續方法基于自動執行腳本，以最大程度地減少在開發應用程式時引入錯誤的機會。從開發新代碼到部署新代碼，他們幾乎不需要人工幹預，甚至根本不需要幹預。
它涉及到在每次小的疊代中就不斷地建構、測試和部署代碼更改，進而減少了基于已經存在bug或失敗的先前版本開發新代碼的機會。
Continuous Integration（持續內建）
假設一個應用程式，其代碼存儲在GitLab的Git倉庫中。開發人員每天都要多次推送代碼更改。對于每次向倉庫的推送，你都可以建立一組腳本來自動建構和測試你的應用程式，進而減少了向應用程式引入錯誤的機會。這種做法稱為持續內建，對于送出給應用程式（甚至是開發分支）的每項更改，它都會自動連續進行建構和測試，以確定所引入的更改通過你為應用程式建立的所有測試，準則和代碼合規性标準。
Continuous Delivery（持續傳遞）
持續傳遞是超越持續內建的更進一步的操作。應用程式不僅會在推送到代碼庫的每次代碼更改時進行建構和測試，而且，盡管部署是手動觸發的，但作為一個附加步驟，它也可以連續部署。此方法可確定自動檢查代碼，但需要人工幹預才能從政策上手動觸發以必輸此次變更。
Continuous Deployment（持續部署）
與持續傳遞類似，但不同之處在于，你無需将其手動部署，而是将其設定為自動部署。完全不需要人工幹預即可部署你的應用程式。
1.1. 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 -yrun-test: script: - ruby --version 6 before_script屬性将在運作任何内容之前為你的應用安裝依賴，一個名為run-test的job（作業）将列印目前系統的Ruby版本。二者共同構成了在每次推送到倉庫的任何分支時都會被觸發的pipeline（管道）。
GitLab CI/CD不僅可以執行你設定的job，還可以顯示執行期間發生的情況，正如你在終端看到的那樣：
為你的應用建立政策，GitLab會根據你的定義來運作pipeline。你的管道狀态也會由GitLab顯示：
最後，如果出現任何問題，可以輕松地復原所有更改：
1.2. 基本 CI/CD 工作流程
一旦你将送出推送到遠端倉庫的分支上，那麼你為該項目設定的CI/CD管道将會被觸發。
GitLab CI/CD 通過這樣做：
- 運作自動化腳本（串行或并行） 代碼Review并獲得準許
- 建構并測試你的應用
- 就像在你本機中看到的那樣，使用Review Apps預覽每個合并請求的更改
- 代碼Review并獲得準許
- 合并feature分支到預設分支，同時自動将此次更改部署到生産環境
- 如果出現問題，可以輕松復原
通過GitLab UI所有的步驟都是可視化的：
1.3. 深入了解CI/CD基本工作流程
如果我們深入研究基本工作流程，則可以在DevOps生命周期的每個階段看到GitLab中可用的功能，如下圖所示：
1. Verify
- 通過持續內建自動建構和測試你的應用程式
- 使用GitLab代碼品質（GitLab Code Quality）分析你的源代碼品質
- 通過浏覽器性能測試（Browser Performance Testing）确定代碼更改對性能的影響
- 執行一系列測試，比如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
- 持續部署，自動将你的應用程式部署到生産環境
- 持續傳遞，手動點選以将你的應用程式部署到生産環境
- 用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）檢查應用程式漏洞
2. GitLab CI/CD 快速開始
.gitlab-ci.yml檔案告訴GitLab Runner要做什麼。一個簡單的管道通常包括三個階段：build、test、deploy
管道在 CI/CD > Pipelines 頁面
2.1. 建立一個 .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下的指令
2.2. 推送 .gitlab-ci.yml 到 GitLab
git add .gitlab-ci.ymlgit commit -m "Add .gitlab-ci.yml" git push origin master 2.3. 配置一個Runner
在GitLab中，Runner運作你定義在.gitlab-ci.yml中的作業（job）
一個Runner可以是一個虛拟機、實體機、docker容器，或者一個容器叢集
GitLab與Runner之間通過API進行通信，是以隻需要Runner所在的機器有網絡并且可以通路GitLab伺服器即可
你可以去 Settings ➔ CI/CD 看是否已經有Runner關聯到你的項目，設定Runner簡單又直接
2.4. 檢視 pipeline 和 jobs的狀态
在成功配置Runner以後，你應該可以看到你最近的送出的狀态
為了檢視所有jobs，你可以去 Pipelines ➔ Jobs 頁面
通過點選作業的狀态，你可以看到作業運作的日志
回顧一下：
1、首先，定義.gitlab-ci.yml檔案。在這個檔案中就定義了要執行的job和指令
2、接着，将檔案推送至遠端倉庫
3、最後，配置Runner，用于運作job
3. Auto DevOps
Auto DevOps 提供了預定義的CI/CD配置，使你可以自動檢測，建構，測試，部署和監視應用程式。借助CI/CD最佳實踐和工具，Auto DevOps旨在簡化成熟和現代軟體開發生命周期的設定和執行。
借助Auto DevOps，軟體開發過程的設定變得更加容易，因為每個項目都可以使用最少的配置來完成從驗證到監視的完整工作流程。隻需推送你的代碼，GitLab就會處理其他所有事情。這使得啟動新項目更加容易，并使整個公司的應用程式設定方式保持一緻。
下面這個例子展示了如何使用Auto DevOps将GitLab.com上托管的項目部署到Google Kubernetes Engine
示例中會使用GitLab原生的Kubernetes內建，是以不需要再單獨手動建立Kubernetes叢集
本例将建立并部署一個從GitLab模闆建立的應用
3.1. 從GitLab模闆建立項目
在建立Kubernetes叢集并将其連接配接到GitLab項目之前，你需要一個Google Cloud Platform帳戶
下面使用GitLab的項目模闆來建立一個新項目
給項目起一個名字，并確定它是公有的
3.2. 從GitLab模闆建立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
最後選擇部署政策
一旦你已經完成了以上所有的操作，那麼一個新的 pipeline 将會被自動建立。為了檢視pipeline，可以去 CI/CD > Pipelines
3.4. 部署應用
到目前為止，你應該看到管道正在運作，但是它到底在運作什麼呢？
管道内部分為4個階段，我們可以檢視每個階段有幾個作業在運作，如下圖：
建構 -> 測試 -> 部署 -> 性能測試
現在，應用已經成功部署，讓我們通過浏覽器檢視。
首先，導航到 Operations > Environments
在Environments中，可以看到部署的應用的詳細資訊。在最右邊有三個按鈕，我們依次來看一下：
第一個圖示将打開在生産環境中部署的應用程式的URL。這是一個非常簡單的頁面，但重要的是它可以正常工作！
緊挨着第二個是一個帶小圖像的圖示，Prometheus将在其中收集有關Kubernetes叢集以及應用程式如何影響它的資料（在記憶體/ CPU使用率，延遲等方面）
第三個圖示是Web終端，它将在運作應用程式的容器内打開終端會話。
4. Examples
使用GitLab CI/CD部署一個Spring Boot應用。快速上手Spring Boot請關注公衆号Java技術棧回複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 5. Docs
https://about.gitlab.com/solutions/kubernetes/
https://docs.gitlab.com/ee/ci/README.html
https://docs.gitlab.com/ee/ci/introduction/
https://docs.gitlab.com/ee/topics/autodevops/
https://docs.gitlab.com/ee/ci/examples/README.html
end