CI / CD方法簡介
軟件開發的持續集成基於自動執行腳本，以最大限度地減少在開發應用程序時引入錯誤的可能性。從新代碼的開發到部署，它們需要較少的人為干預甚至根本不需要干預。
它涉及在每次小迭代中不斷構建，測試和部署代碼更改，從而減少基於有缺陷或失敗的先前版本開發新代碼的風險。
這有三種主要方法，每種方法都根據最適合您的策略進行應用。
持續集成（Continuous Integration, 簡稱CI）
考慮一個應用程序，其代碼存儲在GitLab中的Git存儲庫中。開發人員每天多次推送代碼更改。對於每次推送到存儲庫，您都可以創建一組腳本來自動構建和測試應用程序，從而減少向應用程序引入錯誤的可能性。
這種做法被稱為持續集成 ; 對於提交給應用程序的每個更改 - 甚至是開發分支 - 它都是自動且連續地構建和測試的，確保所引入的更改通過您為應用程序建立的所有測試，指南和代碼合規性標准。
GitLab本身就是使用持續集成作為軟件開發方法的一個例子。對於項目的每次推送，都會有一組腳本來檢查代碼。
持續交付（Continuous Delivery，簡稱CD）
持續交付是持續集成的一個步驟。您的應用程序不僅在推送到代碼庫的每個代碼更改時都構建和測試，而且，作為一個額外的步驟，它也會連續部署，盡管部署是手動觸發的。
此方法可確保自動檢查代碼，但需要人工干預才能手動並策略性地觸發更改的部署。
持續部署 （Continuous Deployment， 簡稱CD）
持續部署 也是持續集成的又一步，類似於持續交付。不同之處在於，您不必手動部署應用程序，而是將其設置為自動部署。完全不需要人工干預就可以部署您的應用程序。
GitLab CI / CD簡介
GitLab CI / CD是GitLab內置的強大工具，允許您將所有連續方法（持續集成，交付和部署）應用於您的軟件，而無需第三方應用程序或集成。
GitLab CI / CD的工作原理
要使用GitLab CI / CD，您只需要一個托管在Git存儲庫中的應用程序代碼庫，並在一個名為的文件中指定構建，測試和部署腳本，該文件.gitlab-ci.yml位於存儲庫的根路徑中。
在此文件中，您可以定義要運行的腳本，定義包含和緩存依賴項，選擇要按順序運行的命令以及要並行運行的命令，定義要部署應用程序的位置，以及指定是否將要自動運行腳本或手動觸發任何腳本。熟悉GitLab CI / CD后，您可以在配置文件中添加更多高級步驟。
要向該文件添加腳本，您需要按照適合您的應用程序的順序組織它們，並且與您希望執行的測試一致。要想象可視化過程，請假設您添加到配置文件中的所有腳本與您在計算機終端上運行的命令相同。
將.gitlab-ci.yml配置文件添加到存儲庫后，GitLab將檢測到它並使用名為GitLab Runner的工具運行腳本，該工具與終端類似。
腳本被分組到作業中，它們一起組成一個管道。.gitlab-ci.yml文件的極簡主義示例可以包含：
before_script: - apt-get install rubygems ruby-dev -y run-test: script: - ruby --version
該before_script屬性將在運行任何內容之前為您的應用程序安裝依賴項，並且調用 的 作業run-test將打印當前系統的Ruby版本。它們都構成了在每次推送到存儲庫的任何分支時觸發的管道。
GitLab CI / CD不僅可以執行您設置的作業，還可以顯示執行過程中發生的情況，如終端中所示：
您可以為應用創建策略，GitLab會根據您定義的內容為您運行管道。您的管道狀態也由GitLab顯示：
最后，如果出現任何問題，您可以輕松 回滾所有更改：
基本CI / CD工作流程
請考慮以下示例，了解GitLab CI / CD如何適合常見的開發工作流程。
假設您已在一個問題中討論過代碼實現，並在本地處理您提出的更改。將提交推送到GitLab中遠程存儲庫中的功能分支后，將觸發為項目設置的CI / CD管道pipeline。通過這樣運行GitLab CI / CD：
- 運行自動腳本（順序或並行）到：
- 構建並測試您的應用。
- 使用“評論應用”預覽每個合並請求的更改，如您所見
localhost。
一旦您對實施感到滿意：
- 讓您的代碼經過審核和批准。
- 將功能分支合並到默認分支。
- GitLab CI / CD會自動將更改部署到生產環境中。
- 最后，如果出現問題，您和您的團隊可以輕松地將其回滾。
GitLab CI / CD能夠做得更多，但這個工作流程體現了GitLab跟蹤整個過程的能力，而無需任何外部工具來交付您的軟件。而且，最有用的是，您可以通過GitLab UI可視化所有步驟。
深入了解CI / CD基本工作流程
如果我們深入了解基本工作流程，我們可以在DevOps生命周期的每個階段看到GitLab中可用的功能，如下圖所示。
如果您從左到右查看圖像，您將看到GitLab根據每個階段（驗證，打包，發布）提供的一些功能。
- 驗證：
- 使用持續集成自動構建和測試您的應用程序。
- 使用GitLab代碼質量分析您的源代碼質量。
- 使用瀏覽器性能測試確定代碼更改對性能的影響。
- 執行一系列測試，例如Container Scanning ，依賴掃描 和JUnit測試。
- 使用Review Apps部署您的更改，以預覽每個分支上的應用程序更改。
- 套餐：
- 使用Container Registry存儲Docker鏡像。
- 使用NPM Registry存儲NPM包。
- 使用Maven存儲庫存儲Maven工件。
- 發布：
- 持續部署，自動將您的應用部署到生產環境。
- 持續交付，手動點擊將您的應用部署到生產環境。
- 使用GitLab Pages部署靜態網站。
- 只向部分pod提供功能，並允許一部分用戶群使用Canary Deployments訪問臨時部署的功能。
- 在功能標志后面部署功能。
- 使用GitLab Releases向任何Git標簽添加發行說明。
- 查看使用部署板在Kubernetes上運行的每個CI環境的當前運行狀況和狀態。
- 使用Auto Deploy將應用程序部署到Kubernetes集群中的生產環境。
使用GitLab CI / CD，您還可以：
- 使用Auto DevOps輕松設置應用程序的整個生命周期。
- 將您的應用程序部署到不同的環境。
- 安裝自己的GitLab Runner。
- 安排管道。
- 使用安全測試報告檢查應用程序漏洞。
要查看所有CI / CD功能，請導航回CI / CD索引。
觀看視頻GitLab CI Live Demo，深入了解GitLab CI / CD。
首次設置GitLab CI / CD
要開始使用GitLab CI / CD，您需要熟悉.gitlab-ci.yml配置文件語法及其屬性。
本文檔介紹了GitLab CI / CD在GitLab頁面范圍內的概念，用於部署靜態網站。雖然它適用於想要從頭開始編寫自己的Pages腳本的用戶，但它也可以作為GitLab CI / CD設置過程的介紹。它涵蓋了編寫CI / CD配置文件的第一個常規步驟，因此我們建議您通讀它以了解GitLab的CI / CD邏輯，並學習如何為任何應用程序編寫自己的腳本（或調整現有腳本）。
有關GitLab的CI / CD配置選項的深入視圖，請查看 .gitlab-ci.yml完整參考。
GitLab CI / CD入門
GitLab提供持續集成服務。如果 將.gitlab-ci.yml文件添加到存儲庫的根目錄，並將GitLab項目配置為使用Runner，則每次提交或推送都會觸發CI 管道。
該.gitlab-ci.yml文件告訴GitLab執行者該做什么。默認情況下，它運行有三個流水線階段：build，test，和deploy。你不需要使用所有三個階段; 沒有工作的階段被忽略了。
如果一切運行正常（沒有非零返回值），您將獲得與提交相關聯的漂亮綠色復選標記。這樣可以在查看代碼之前輕松查看提交是否導致任何測試失敗。
大多數項目使用GitLab的CI服務來運行測試套件，以便開發人員在破壞某些內容時立即獲得反饋。
使用持續交付和持續部署將測試代碼自動部署到登台和生產環境的趨勢越來越明顯。
簡而言之，具有工作CI所需的步驟可歸納為：
- 添加
.gitlab-ci.yml到存儲庫的根目錄 - 配置一個Runner
從那時起，在每次推送到Git存儲庫時，Runner將自動啟動管道，管道將顯示在項目的Pipelines頁面下。
本指南假設您擁有：
- 一個正在運行的版本8.0 + r的GitLab實例或正在使用 GitLab.com。
- GitLab中的一個項目，您希望使用CI。
- 維護者或所有者訪問項目
讓我們把它分解成碎片並努力解決GitLab CI難題。
創建.gitlab-ci.yml文件
在您創建之前，.gitlab-ci.yml讓我們先簡要解釋一下這是什么。
什么是 .gitlab-ci.yml
.gitlab-ci.yml您可以在該文件中配置CI對項目執行的操作。它位於存儲庫的根目錄中。
在對存儲庫的任何推送中，GitLab將根據文件的內容查找.gitlab-ci.yml 文件並在Runners上啟動作業。
因為.gitlab-ci.yml在存儲庫中並且受版本控制，舊版本仍然可以成功構建，分支可以輕松地使用CI，分支可以具有不同的管道和作業，並且您具有CI的單一事實來源。您可以.gitlab-ci.yml 在我們的博客中詳細了解我們使用它的原因。
創建一個簡單的.gitlab-ci.yml文件
注意：
.gitlab-ci.yml是一個YAML文件，因此您必須特別注意縮進。始終使用空格，而不是制表符。
您需要創建一個.gitlab-ci.yml在存儲庫的根目錄中命名的文件。下面是Ruby on Rails項目的示例。
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
這是最簡單的配置，適用於大多數Ruby應用程序：
- 使用要執行的不同命令定義兩個作業
rspec和rubocop（名稱是任意的）。 - 在每個作業之前，
before_script執行定義的命令。
該.gitlab-ci.yml文件定義了具有運行方式和時間限制的作業集。該工作被定義為一個名稱頂層元素（在我們的情況rspec和rubocop），並總是要包含script關鍵詞。作業用於創建作業，然后由執行者選擇並在執行者的環境中執行。
重要的是每項工作都是相互獨立運作的。
如果要檢查.gitlab-ci.yml項目是否有效，/-/ci/lint項目命名空間的頁面下會有一個Lint工具。您還可以在CI / CD下找到“CI Lint”按鈕進入此頁面➔管道和 管道➔項目中的作業。
有關更多信息和完整.gitlab-ci.yml語法，請閱讀 .gitlab-ci.yml上的參考文檔。
推
.gitlab-ci.yml送到GitLab創建之后
.gitlab-ci.yml，您應該將其添加到Git存儲庫並將其推送到GitLab。現在，如果您轉到“ 管道”頁面，您將看到管道處於待處理狀態。
您也可以轉到“ 提交”頁面，注意提交SHA旁邊的小暫停圖標。
單擊它，您將被定向到該特定提交的作業頁面。
請注意，有一個掛起的作業以我們寫的內容命名
.gitlab-ci.yml。“卡住”表示尚未為此作業配置Runner。下一步是配置一個Runner，以便它選擇掛起的作業。
配置Runner
在GitLab中，Runners運行您定義的作業
.gitlab-ci.yml。Runner可以是虛擬機，VPS，裸機，docker容器甚至是容器集群。GitLab和Runners通過API進行通信，因此唯一的要求是Runner的機器可以訪問GitLab服務器。Runner可以特定於某個項目，也可以在GitLab中提供多個項目。如果它服務於所有項目，則稱為共享運行者。
在Runners文檔中查找有關不同Runners的更多信息 。
您可以通過轉到設置➔CI/ CD找到是否為您的項目分配了任何執行者 。設置一個Runner既簡單又直接。由GitLab支持的官方Runner是用Go編寫的，其文檔可以在https://docs.gitlab.com/runner/找到。
要獲得功能性Runner，您需要執行以下兩個步驟：
按照上面的鏈接設置您自己的Runner或使用Shared Runner，如下一節所述。
設置好Runner后，您應該按照設置➔CI/ CD在項目的Runners頁面上看到它。
共享執行者
如果您使用GitLab.com，您可以使用 GitLab Inc.提供的共享執行者。
這些是在GitLab的基礎架構上運行的特殊虛擬機，可以構建任何項目。
要啟用共享運行器，您必須轉到項目的 設置➔CI/ CD，然后單擊啟用共享運行器。
閱讀共享執行者的更多信息。
查看管道和作業的狀態
成功配置Runner后，您應該會看到上次提交的狀態從掛起更改為運行，成功或失敗。
您可以轉到項目的“ 管道”頁面來查看所有管道。
或者您可以通過管道➔工作頁面查看所有工作。
通過單擊作業的狀態，您將能夠看到該作業的日志。這對於診斷工作失敗或行為與預期不同的原因非常重要。
您還可以在GitLab的各個頁面中查看任何提交的狀態，例如提交和合並請求。
例子
訪問示例README，查看使用各種語言的GitLab CI的示例列表。
GitLab CI / CD示例
此頁面包含各種示例的鏈接，這些示例可幫助您了解如何針對特定用例實施GitLab CI / CD。
示例有多種形式。作為一個集合：
.gitlab-ci.yml在GitLab中維護的模板文件。當您通過UI創建新文件時，GitLab將為您提供選擇其中一個模板的選項。這將允許您快速引導項目以進行CI / CD。如果您缺少您喜歡的編程語言或框架，我們會非常樂意通過向.gitlab-ci.yml此項目發送新的合並請求來提供幫助。CI / CD示例
下表列出了本節中包含的分步教程的示例。
dpl的部署工具。貢獻的例子
歡迎捐款！您可以通過發送包含該語言指南的合並請求來幫助您喜愛的編程語言用戶和GitLab。您可能想申請GitLab社區作家計划 ，以便為GitLab撰寫完整的文章而獲得報酬。
將模板添加到GitLab安裝中
如果您希望為團隊提供自己管理的GitLab實例的自定義示例和模板，GitLab管理員可以指定一個實例模板存儲庫，其中包含特定於您的企業的示例和模板。
其他資源
本節提供了更多資源，可幫助您熟悉GitLab CI / CD的各種用途。請注意，較舊的文章和視頻可能無法反映最新GitLab版本的狀態。
雲中的CI / CD
有關為基於雲的環境設置GitLab CI / CD的示例，請參閱：
另請參閱以下視頻概述：
客戶故事
有關GitLab CI / CD的一些客戶體驗，請參閱：
入門
有關幫助您入門的示例，請參閱：
實施GitLab CI / CD
有關已實施GitLab CI / CD的其他人的示例，請參閱：
從第三方CI工具遷移到GitLab
將GitLab CI / CD與其他系統集成
要了解如何將GitLab CI / CD與第三方系統集成，請參閱：
移動開發
有關使用GitLab CI / CD進行移動應用程序開發的幫助，請參閱：