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 顯示：
最後，如果出現任何問題，可以輕鬆地回滾所有更改：
基本 CI/CD 工作流程
一旦你將提交推送到遠程倉庫的分支上，那麼你爲該項目設置的 CI/CD 管道將會被觸發。GitLab CI/CD 通過這樣做：
運行自動化腳本（串行或並行） 代碼Review並獲得批准
-
構建並測試你的應用
就像在你本機中看到的那樣，使用 Review Apps 預覽每個合併請求的更改
代碼 Review 並獲得批准
合併 feature 分支到默認分支，同時自動將此次更改部署到生產環境
如果出現問題，可以輕鬆回滾
通過 GitLab UI 所有的步驟都是可視化的 。
深入瞭解CI/CD基本工作流程
如果我們深入研究基本工作流程，則可以在 DevOps 生命週期的每個階段看到 GitLab 中可用的功能，如下圖所示：
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 簡單又直接。
查看 Pipeline 和 jobs 的狀態
在成功配置 Runner 以後，你應該可以看到你最近的提交的狀態。
爲了查看所有 jobs，你可以去 Pipelines ➔ Jobs 頁面。
通過點擊作業的狀態，你可以看到作業運行的日誌。
回顧一下：
首先，定義 .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 的項目模板來創建一個新項目。
給項目起一個名字，並確保它是公有的。
從 GitLab 模板創建 Kubernetes 集羣
點擊 Add Kubernetes cluster 按鈕，或者 Operations > Kubernetes。
安裝 Helm，Ingress 和 Prometheus。
啓用 Auto DevOps（可選）
Auto DevOps 默認是啓用的。
導航欄 Settings > CI/CD > Auto DevOps。
勾選 Default to Auto DevOps pipeline。
最後選擇部署策略。
一旦你已經完成了以上所有的操作，那麼一個新的 Pipeline 將會被自動創建。爲了查看 Pipeline，可以去 CI/CD > Pipelines。
部署應用
到目前爲止，你應該看到管道正在運行，但是它到底在運行什麼呢？
管道內部分爲4個階段，我們可以查看每個階段有幾個作業在運行，如下圖：
構建 -> 測試 -> 部署 -> 性能測試
現在，應用已經成功部署，讓我們通過瀏覽器查看。
首先，導航到 Operations > Environments。
在 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
原文鏈接：https://www.cnblogs.com/cjsblog/p/12256843.html
Kubernetes實戰培訓
Kubernetes實戰培訓將於2020年12月25日在深圳開課，3天時間帶你係統掌握Kubernetes，學習效果不好可以繼續學習。本次培訓包括：雲原生介紹、微服務；Docker基礎、Docker工作原理、鏡像、網絡、存儲、數據卷、安全；Kubernetes架構、核心組件、常用對象、網絡、存儲、認證、服務發現、調度和服務質量保證、日誌、監控、告警、Helm、實踐案例等，點擊下方圖片或者閱讀原文鏈接查看詳情。
