Help us learn about your current experience with the documentation. Take the survey.

从 CircleCI 迁移

版本：免费版、高级版、旗舰版
提供：GitLab.com、GitLab 自托管、GitLab 专用

如果您目前正在使用 CircleCI，可以将您的 CI/CD pipeline 迁移到 GitLab CI/CD，并开始利用其所有强大的功能。

我们整理了一些您在开始迁移前可能会觉得有用的资源。

快速入门指南是了解 GitLab CI/CD 工作原理的良好概述。您可能还对 Auto DevOps 感兴趣，它可以在几乎无需任何配置的情况下构建、测试和部署您的应用程序。

对于高级 CI/CD 团队，自定义项目模板可以实现 pipeline 配置的复用。

如果您有这里未解答的问题，GitLab 社区论坛是一个很好的资源。

`config.yml` 与 `.gitlab-ci.yml` 的对比

CircleCI 的 config.yml 配置文件定义了脚本、任务和工作流（在 GitLab 中称为 “stages”）。在 GitLab 中，采用类似的方法，在仓库的根目录中使用 .gitlab-ci.yml 文件。

任务（Jobs）

在 CircleCI 中，jobs 是执行特定任务的一系列步骤。在 GitLab 中，jobs 也是配置文件中的基本元素。由于仓库会自动获取，GitLab CI/CD 中不需要 checkout 关键字。

CircleCI 任务定义示例：

jobs:
  job1:
    steps:
      - checkout
      - run: "execute-script-for-job1"

GitLab CI/CD 中相同任务定义的示例：

job1:
  script: "execute-script-for-job1"

Docker 镜像定义

CircleCI 在任务级别定义镜像，GitLab CI/CD 也支持这一点。此外，GitLab CI/CD 还支持全局设置，供所有未定义 image 的任务使用。

CircleCI 镜像定义示例：

jobs:
  job1:
    docker:
      - image: ruby:2.6

GitLab CI/CD 中相同镜像定义的示例：

job1:
  image: ruby:2.6

工作流（Workflows）

CircleCI 使用 workflows 确定 jobs 的运行顺序。这也用于确定并发、顺序、定时或手动运行。GitLab CI/CD 中的等效功能称为 stages。同一 stage 中的 jobs 并行运行，并且仅在之前的 stage 完成后运行。默认情况下，当 job 失败时会跳过下一 stage 的执行，但即使在 job 失败后也可以允许继续执行。

有关可使用的不同类型 pipeline 的指导，请参阅 Pipeline 架构概述。Pipeline 可以根据您的需求进行定制，例如用于大型复杂项目或具有独立定义组件的 monorepo。

并行和顺序任务执行

以下示例展示了 jobs 如何并行或顺序运行：

job1 和 job2 并行运行（在 GitLab CI/CD 的 build stage 中）。
job3 仅在 job1 和 job2 成功完成后运行（在 test stage 中）。
job4 仅在 job3 成功完成后运行（在 deploy stage 中）。

使用 workflows 的 CircleCI 示例：

version: 2
jobs:
  job1:
    steps:
      - checkout
      - run: make build dependencies
  job2:
    steps:
      - run: make build artifacts
  job3:
    steps:
      - run: make test
  job4:
    steps:
      - run: make deploy

workflows:
  version: 2
  jobs:
    - job1
    - job2
    - job3:
        requires:
          - job1
          - job2
    - job4:
        requires:
          - job3

GitLab CI/CD 中使用 stages 的相同工作流示例：

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script: make build dependencies

job2:
  stage: build
  script: make build artifacts

job3:
  stage: test
  script: make test

job4:
  stage: deploy
  script: make deploy
  environment: production

定时运行

GitLab CI/CD 有一个易于使用的 UI 来定时运行 pipeline。此外，rules 可用于确定 jobs 是否应包含在或排除在定时 pipeline 中。

CircleCI 定时工作流示例：

commit-workflow:
  jobs:
    - build
scheduled-workflow:
  triggers:
    - schedule:
        cron: "0 1 * * *"
        filters:
          branches:
            only: try-schedule-workflow
  jobs:
    - build

GitLab CI/CD 中使用 rules 的相同定时 pipeline 示例：

job1:
  script:
    - make build
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == "try-schedule-workflow"

保存 pipeline 配置后，您可以在 GitLab UI 中配置 cron 计划，也可以在 UI 中启用或禁用计划。

手动运行

CircleCI 手动工作流示例：

release-branch-workflow:
  jobs:
    - build
    - testing:
        requires:
          - build
    - deploy:
        type: approval
        requires:
          - testing

GitLab CI/CD 中使用 when: manual 的相同工作流示例：

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  when: manual
  environment: production

按分支过滤任务

Rules 是一种机制，用于确定 job 是否针对特定分支运行。

按分支过滤的 CircleCI job 示例：

jobs:
  deploy:
    branches:
      only:
        - main
        - /rc-.*/

GitLab CI/CD 中使用 rules 的相同工作流示例：

deploy:
  stage: deploy
  script:
    - echo "Deploy job"
  rules:
    - if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH =~ /^rc-/
  environment: production

缓存（Caching）

GitLab 提供了一种缓存机制，通过重用之前下载的依赖项来加快您的 job 构建时间。了解 cache 和 artifacts 之间的区别对于充分利用这些功能非常重要。

使用缓存的 CircleCI job 示例：

jobs:
  job1:
    steps:
      - restore_cache:
          key: source-v1-< .Revision >
      - checkout
      - run: npm install
      - save_cache:
          key: source-v1-< .Revision >
          paths:
            - "node_modules"

GitLab CI/CD 中使用 cache 的相同 pipeline 示例：

test_async:
  image: node:latest
  cache:  # Cache modules in between jobs
    key: $CI_COMMIT_REF_SLUG
    paths:
      - .npm/
  before_script:
    - npm ci --cache .npm --prefer-offline
  script:
    - node ./specs/start.js ./specs/async.spec.js

上下文（Contexts）和变量

CircleCI 提供 Contexts 来安全地跨项目 pipeline 传递环境变量。在 GitLab 中，可以创建一个 Group 来将相关项目组合在一起。在 group 级别，CI/CD variables 可以存储在单个项目之外，并安全地传递到多个项目的 pipeline 中。

Orbs

有两个 GitLab issue 正在处理 CircleCI Orbs 以及 GitLab 如何实现类似功能。

构建环境

CircleCI 提供 executors 作为运行特定 job 的底层技术。在 GitLab 中，这是通过 runners 实现的。

支持以下环境：

自托管 runners：

Linux
Windows
macOS

GitLab.com 实例 runners：

Linux
Windows（测试版）。
macOS（测试版）。

机器和特定构建环境

Tags 可用于在不同平台上运行 jobs，通过告诉 GitLab 哪些 runners 应该运行这些 jobs。

在特定环境中运行的 CircleCI job 示例：

jobs:
  ubuntuJob:
    machine:
      image: ubuntu-1604:201903-01
    steps:
      - checkout
      - run: echo "Hello, $USER!"
  osxJob:
    macos:
      xcode: 11.3.0
    steps:
      - checkout
      - run: echo "Hello, $USER!"

GitLab CI/CD 中使用 tags 的相同 job 示例：

windows job:
  stage: build
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

osx job:
  stage: build
  tags:
    - osx
  script:
    - echo "Hello, $USER!"