Migrating from Jenkins · Gitlab 中文文檔

# Migrating from Jenkins > 原文：[https://docs.gitlab.com/ee/ci/jenkins/](https://docs.gitlab.com/ee/ci/jenkins/) * [Managing the organizational transition](#managing-the-organizational-transition) * [JenkinsFile Wrapper](#jenkinsfile-wrapper) * [Important product differences](#important-product-differences) * [Agents vs. Runners](#agents-vs-runners) * [Groovy vs. YAML](#groovy-vs-yaml) * [Artifact publishing](#artifact-publishing) * [Integrated features](#integrated-features) * [Templates](#templates) * [Converting a declarative Jenkinsfile](#converting-a-declarative-jenkinsfile) * [Sections](#sections) * [`agent`](#agent) * [`post`](#post) * [`stages`](#stages) * [`steps`](#steps) * [Directives](#directives) * [`environment`](#environment) * [`options`](#options) * [`parameters`](#parameters) * [`triggers` / `cron`](#triggers--cron) * [`tools`](#tools) * [`input`](#input) * [`when`](#when) # Migrating from Jenkins[](#migrating-from-jenkins "Permalink") 許多 GitLab 用戶已經從 Jenkins 成功遷移到 GitLab CI / CD. 為了使您入門時更容易，我們在這里收集了一些您可能會在使用之前可能會發現有用的資源.請將此頁面視為" Jenkins 用戶的 GitLab CI / CD"指南. 建議的步驟的以下列表是在觀察能夠快速完成此遷移的組織之后創建的： 1. 首先閱讀《 GitLab CI / CD [快速入門指南》](../quick_start/README.html)和[重要的產品差異](#important-product-differences) . 2. 了解[管理組織過渡](#managing-the-organizational-transition)的重要性. 3. [將 Runners 添加](../runners/README.html)到您的 GitLab 實例. 4. 教育開發人員并使他們能夠在他們的項目中獨立執行以下步驟： 1. 查看《 [快速入門指南](../quick_start/README.html)和[管道配置參考》](../yaml/README.html) . 2. 使用[Jenkins 包裝器](#jenkinsfile-wrapper)暫時維護脆弱的 Jenkins 作業. 3. 遷移構建和 CI 作業并將其配置為直接在合并請求中顯示結果. 他們可以使用[Auto DevOps](../../topics/autodevops/index.html)作為起點，并[根據](../../topics/autodevops/customize.html)需要[自定義](../../topics/autodevops/customize.html)或[分解](../../topics/autodevops/customize.html#using-components-of-auto-devops)配置. 4. 添加[評論應用](../review_apps/index.html) . 5. 使用[云部署模板](../cloud_deployment/index.html) ，添加[環境](../environments/index.html)和[部署板](../..//user/project/deploy_boards.html)來遷移部署作業. 6. 使用 Jenkins 包裝器解開仍在運行的所有作業的包裝. 5. 盤點所有常見的 CI / CD 作業定義，然后為其創建和共享[模板](#templates) . 有關如何將 Jenkins 管道轉換為 GitLab CI / CD 管道的示例，或如何使用 Auto DevOps 自動測試代碼的示例，請觀看[從 Jenkins 遷移到 GitLab 的](https://www.youtube.com/watch?v=RlEVGOpYF5Y)視頻. 否則，請繼續閱讀以獲取重要信息，這些信息將幫助您取得成功. 歡迎來到 GitLab！如果您有未在此處回答的問題， [GitLab 社區論壇](https://forum.gitlab.com/)將是一個很好的資源. ## Managing the organizational transition[](#managing-the-organizational-transition "Permalink") 從詹金斯過渡到 GitLab 的一個重要部分是隨之而來的文化和組織變革，并成功地對其進行了管理. 我們發現了一些有助于解決問題的方法： * 為您的遷移目標設定并傳達清晰的愿景有助于您的用戶理解為什么值得付出努力. 當工作完成時，該值將很明顯，但是在進行過程中，人們也需要意識到. * 有關領導團隊的贊助和配合有助于上述觀點. * 花時間對用戶進行不同的教育，與他們共享此文檔等等，將有助于確保您成功. * 尋找順序或延遲部分遷移的方法可能會很有幫助，但是您不想讓事物長時間處于未遷移（或部分遷移）狀態. 要獲得 GitLab 的所有好處，僅將現有的 Jenkins 設置轉移到原樣上（包括任何當前問題）是不夠的. 您需要利用 GitLab 提供的改進，這最終需要（最終）更新您的實現. ## JenkinsFile Wrapper[](#jenkinsfile-wrapper "Permalink") 我們正在構建一個[JenkinsFile 包裝器](https://gitlab.com/gitlab-org/jfr-container-builder/) ，它將允許您在 GitLab 作業（包括插件）中運行完整的 Jenkins 實例. 通過讓您將不太緊急的管道的遷移延遲一段時間，可以幫助簡化過渡過程. 如果您有興趣幫助 GitLab 測試包裝器，請加入我們的[公共測試問題](https://gitlab.com/gitlab-org/gitlab/-/issues/215675)以獲取說明并提供您的反饋. ## Important product differences[](#important-product-differences "Permalink") 值得一提的產品之間存在一些高級差異： * 使用 GitLab，您不需要根`pipeline`關鍵字即可包裝所有內容. * 管道觸發和[觸發其他管道的](../yaml/README.html#trigger)方式與詹金斯不同. 可以觸發 GitLab 管道： * 在推 * on [schedule](../pipelines/schedules.html) * 從[GitLab UI](../pipelines/index.html#run-a-pipeline-manually) * by [API call](../triggers/README.html) * by [webhook](../triggers/README.html#triggering-a-pipeline-from-a-webhook) * by [ChatOps](../chatops/README.html) * 您可以使用[`rules`語法](../yaml/README.html#rules)來控制在哪種情況下運行哪些作業，具體取決于觸發方式. * GitLab [管道調度概念](../pipelines/schedules.html)也與 Jenkins 不同. * 您可以使用[`include`關鍵字](../yaml/README.html#include)和[模板](#templates)重復使用管道配置. 您的模板可以保存在中央存儲庫中（具有不同的權限），然后任何項目都可以使用它們. 這個中央項目也可以包含腳本或其他可重用的代碼. * You can also use the [`extends` keyword](../yaml/README.html#extends) to reuse configuration within a single pipeline configuration. * 單個階段中的所有作業始終并行運行，并且所有階段均按順序運行. 我們計劃通過我們的有[向無環圖](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063)功能允許某些作業根據需要中斷此排序. * [`parallel`](../yaml/README.html#parallel)關鍵字可以自動并行化任務，例如支持并行化的測試. * 通常，單個階段中的所有作業并行運行，并且所有階段按順序運行. 有不同的[管道體系結構](../pipelines/pipeline_architectures.html)允許您更改此行為. * 建議使用新[`rules`語法](../yaml/README.html#rules)控制何時運行不同作業. 它比`only/except`語法更強大. * 一個重要的區別是，作業彼此獨立運行，并且每個作業都具有全新的環境. 使用[`artifacts`](../yaml/README.html#artifacts)和[`dependencies`](../yaml/README.html#dependencies)關鍵字控制作業之間傳遞工件. 完成后，計劃的[工作區](https://gitlab.com/gitlab-org/gitlab/-/issues/29265)功能將使您能夠更輕松地在串行作業之間持久保留公共工作區. * `.gitlab-ci.yml`文件已簽入到存儲庫的根目錄，非常類似于 Jenkinsfile，但采用 YAML 格式（請參閱[完整參考](../yaml/README.html) ）而不是 Groovy DSL. 它與聲明性 Jenkinsfile 格式最相似. * 手動批準或登機口可以設置為以下[`when:manual`作業](../yaml/README.html#whenmanual) . 這些還可以利用[`protected environments`](../yaml/README.html#protecting-manual-jobs-premium)來控制誰可以批準它們. * GitLab 帶有[容器注冊表](../../user/packages/container_registry/index.html) ，我們建議使用容器映像來設置您的構建環境. 例如，設置一個管道來構建您自己的構建環境，并將其發布到容器注冊表. 然后，讓您的管道使用此方法，而不是每個管道都使用它們自己的環境，這將變得更慢，并且一致性可能會降低. 我們有大量有關[如何使用 Container Registry 的](../../user/packages/container_registry/index.html)文檔. * 中央實用程序存儲庫是放置各種計劃作業或其他功能類似于實用程序的手動作業的好地方. 詹金斯的裝置中往往有一些. ## Agents vs. Runners[](#agents-vs-runners "Permalink") Jenkins 代理和 GitLab Runners 都是運行作業的主機. 要轉換 Jenkins 代理，只需將其卸載，然后[安裝并注冊 Runner](../runners/README.html) . 運行程序不需要太多的開銷，因此您可以像使用的 Jenkins 代理一樣調整它們的大小. 與代理相比，Runners 的工作方式存在一些重要差異： * 跑步者可以設置為[在實例之間共享，也可以在組級別添加，也可以在項目級別設置](../runners/README.html#types-of-runners) . 他們將從您自動定義的范圍中自動選擇作業. * 您還可以[使用標簽](../runners/README.html#use-tags-to-limit-the-number-of-jobs-using-the-runner)進行更精細的控制，并將跑步者與特定工作相關聯. 例如，您可以將標簽用于需要專用，功能更強大或特定硬件的作業. * GitLab 具有[針對](https://docs.gitlab.com/runner/configuration/autoscale.html) Runner 的[自動縮放功能](https://docs.gitlab.com/runner/configuration/autoscale.html) ，可讓您將其配置為根據需要進行設置，并在不進行縮放時進行縮放. 這類似于詹金斯中的臨時代理. 如果您使用的是`gitlab.com` ，則可以利用我們[共享的 Runner](../../user/gitlab_com/index.html#shared-runners) `gitlab.com`來運行作業，而無需置備自己的 Runners. 我們正在研究使它們也[可用于自我管理實例](https://gitlab.com/groups/gitlab-org/-/epics/835) . ## Groovy vs. YAML[](#groovy-vs-yaml "Permalink") Jenkins 管道基于[Groovy](https://s0groovy-lang0org.icopy.site/) ，因此管道規范以代碼形式編寫. GitLab 的工作方式略有不同，我們使用結構更高級的[YAML](https://yaml.org/)格式，該格式將腳本元素放置在`script:`內部`script:`塊與管道規范本身分開. 這是 GitLab 的優勢，因為它有助于使學習曲線更簡單地啟動和運行，并且避免了一些不受限制的復雜性問題，這些問題會使您的 Jenkinsfile 難以理解和管理. 就是說，我們當然仍然重視 DRY（不要重復自己）的原則，并希望確保您的工作行為可以被一次編碼并根據需要進行應用. 您可以使用`extends:`語法[在您的作業中重用配置](../yaml/README.html#extends) ， `include:`可用于在不同項目的管道中[重用管道配置](../yaml/README.html#include) ： ``` .in-docker: tags: - docker image: alpine rspec: extends: - .in-docker script: - rake rspec ``` ## Artifact publishing[](#artifact-publishing "Permalink") 工件的工作方式可能與您與詹金斯一起使用時有所不同. 在 GitLab 中，任何作業都可以使用`artifacts:`關鍵字定義一組要保存的`artifacts:` . 可以將其配置為指向一個文件或一組文件，然后可以在每個作業之間將其持久化. 閱讀更多關于我們詳細的[工件文檔的信息](../pipelines/job_artifacts.html) ： ``` pdf: script: xelatex mycv.tex artifacts: paths: - ./mycv.pdf - ./output/ expire_in: 1 week ``` 此外，我們還具有包管理功能，例如可以利用的內置容器，NPM 和 Maven 注冊表. 您可以在[我們的文檔](../../README.html#package)的[包裝部分中](../../README.html#package)查看打包功能的完整列表（包括指向文檔的鏈接）. ## Integrated features[](#integrated-features "Permalink") 在 Jenkins 中，您可能曾經使用插件來獲得代碼質量，單元測試，安全掃描等功能，但 GitLab 充分利用了我們連接的生態系統，將這些結果自動提取到您的合并請求，管道詳細信息頁面和其他位置. 您可能會發現實際上不需要配置任何內容即可顯示這些內容. 如果它們無法正常工作，或者您想查看可用的[功能](../README.html#feature-set) ，則我們的[CI 功能索引](../README.html#feature-set)將提供捆綁功能的完整列表，并提供每個功能的文檔鏈接. ### Templates[](#templates "Permalink") 對于高級 CI / CD 團隊，項目模板可以啟用管道配置的重用，并鼓勵內部采購. In self-managed GitLab instances, you can build an [Instance Template Repository](../../user/admin_area/settings/instance_template_repository.html). Development teams across the whole organization can select templates from a dropdown menu. A group administrator is able to set a group to use as the source for the [custom project templates](../../user/admin_area/custom_project_templates.html), which can be used by all projects in the group. An instance administrator can set a group as the source for [instance project templates](../../user/group/custom_project_templates.html), which can be used by projects in that instance. ## Converting a declarative Jenkinsfile[](#converting-a-declarative-jenkinsfile "Permalink") 聲明性 Jenkinsfile 包含用于控制管道行為的" Sections"和" Directives". GitLab 中有所有這些的等效項，我們在下面對此進行了介紹. 本節基于[Jenkinsfile 語法文檔](https://www.jenkins.io/doc/book/pipeline/syntax/) ，旨在將其中的概念映射到 GitLab 中的概念. ### Sections[](#sections "Permalink") #### `agent`[](#agent "Permalink") 代理部分用于定義如何執行管道. 對于 GitLab，我們使用[GitLab Runner](../runners/README.html)來提供此功能. 您可以在 Kubernetes 或任何主機上配置自己的運行程序，也可以利用我們的共享運行程序隊列（請注意，共享運行程序隊列僅適用于 GitLab.com 用戶.）以上鏈接將帶您進入說明文檔的文檔如何快速起步和運行. 我們還支持使用[標簽](../runners/README.html#use-tags-to-limit-the-number-of-jobs-using-the-runner)將不同的作業定向到不同的 Runner（執行代理）. `agent`部分還允許您定義應使用哪些 Docker 映像執行，而我們使用[`image`](../yaml/README.html#image)關鍵字. 該`image`可以設置在單個作業或頂層，在這種情況下，它將應用于管道中的所有作業： ``` my_job: image: alpine ... ``` #### `post`[](#post "Permalink") `post`部分定義了應在管道末尾執行的操作. GitLab 也通過階段的使用來支持這一點. 您可以按以下方式定義階段，分配給`before_pipeline`或`after_pipeline`階段的所有作業都將按預期運行. 您可以根據需要將這些階段稱為： ``` stages: - before_pipeline - build - test - deploy - after_pipeline ``` 可以通過[`before_script`和`after_script`關鍵字](../yaml/README.html#before_script-and-after_script)設置要在任何作業之前和之后執行的步驟： ``` default: before_script: - echo "I run before any jobs starts in the entire pipeline, and can be responsible for setting up the environment." ``` #### `stages`[](#stages "Permalink") GitLab CI / CD 也可以讓您定義階段，但是可以自由配置一些. GitLab [`stages`關鍵字](../yaml/README.html#stages)是一個頂級設置，它枚舉了階段列表，但是您不需要在" `stages`部分下嵌套單個作業. 通過使用[`stage:`關鍵字，](../yaml/README.html#stage)可以使`.gitlab-ci.yml`定義的任何作業成為任何階段的一部分. 請注意，除非另有說明，否則每個管道都以`build` ， `test`和`deploy`階段實例化，并按該順序運行. 未定義`stage`作業默認情況下放置在`test`階段. 當然，引用階段的每個作業都必須引用管道配置中存在的階段. ``` stages: - build - test - deploy my_job: stage: build ... ``` #### `steps`[](#steps "Permalink") The `steps` section is equivalent to the [`script` section](../yaml/README.html#script) of an individual job. This is a simple YAML array with each line representing an individual command to be run: ``` my_job: script: - echo "hello! the current time is:" - time ... ``` ### Directives[](#directives "Permalink") #### `environment`[](#environment "Permalink") 在 GitLab 中，我們使用[`variables`關鍵字](../yaml/README.html#variables)在運行時定義不同的變量. 這些也可以通過 CI / CD 設置下的 GitLab UI 進行設置. 另請參閱我們[有關變量](../variables/README.html)的[一般文檔](../variables/README.html) ，包括有關[受保護變量](../variables/README.html#protect-a-custom-variable)的部分，該部分可用于將對某些變量的訪問限制為某些環境或運行程序： ``` variables: POSTGRES_USER: user POSTGRES_PASSWORD: testing_password ``` #### `options`[](#options "Permalink") 這里，存在與所討論的對象本身相關聯的用于不同事物的選項. 例如，與作業相關的選項是相對于作業本身定義的. 如果您正在尋找某個選項，則應該可以通過搜索[完整的配置參考](../yaml/README.html)頁面來找到它的位置. #### `parameters`[](#parameters "Permalink") GitLab 不需要您定義在開始手動作業時希望可用的變量. 用戶可以提供他們喜歡的任何變量. #### `triggers` / `cron`[](#triggers--cron "Permalink") Because GitLab is integrated tightly with Git, SCM polling options for triggers are not needed. We support an easy to use [syntax for scheduling pipelines](../pipelines/schedules.html). #### `tools`[](#tools "Permalink") GitLab 不支持單獨的`tools`指令. 我們的最佳實踐建議是使用預構建的容器映像，該映像可以緩存，并且可以構建為包含管道所需的工具. 可以設置管道以根據需要自動構建這些映像，并將它們部署到[容器注冊表中](../../user/packages/container_registry/index.html) . 如果您沒有在 Docker / Kubernetes 上使用容器映像，例如在 Mac 或 FreeBSD 上，則`shell`執行程序確實需要您預先設置環境或作為作業的一部分. 您可以創建一個`before_script`動作來為您處理. #### `input`[](#input "Permalink") 與`parameters`關鍵字類似，這是不需要的，因為始終可以為運行時變量條目提供手動作業. #### `when`[](#when "Permalink") GitLab 確實支持[`when`關鍵字](../yaml/README.html#when) ，用于指示在（或盡管發生）故障的情況下應在何時運行作業，但是大多數用于控制管道的邏輯都可以在我們功能非常強大的[`only/except`規則系統中找到](../yaml/README.html#onlyexcept-basic) （另請參見[高級語法](../yaml/README.html#onlyexcept-basic) ）： ``` my_job: only: [branches] ```