Migrating from CircleCI

原文：https://docs.gitlab.com/ee/ci/migration/circleci.html

Migrating from CircleCI

如果您当前正在使用 CircleCI，则可以将 CI / CD 管道迁移到GitLab CI / CD ，并开始使用其所有强大功能. 查看我们的CircleCI 与 GitLab比较，以了解有什么不同.

在开始迁移之前，我们已经收集了一些您可能会觉得有用的资源.

快速入门指南很好地概述了 GitLab CI / CD 的工作方式. 您可能还对Auto DevOps感兴趣，可以将其用于构建，测试和部署应用程序，而几乎不需要或根本不需要进行任何配置.

对于高级 CI / CD 团队， 自定义项目模板可以启用管道配置的重用.

如果您有未在此处回答的问题， GitLab 社区论坛将是一个很好的资源.

config.yml vs gitlab-ci.yml

CircleCI 的config.yml配置文件定义了脚本，作业和工作流程（在 GitLab 中称为”阶段”）. 在 GitLab 中，对存储库根目录中的.gitlab-ci.yml文件使用类似的方法.

Jobs

在 CircleCI 中，作业是执行特定任务的步骤的集合. 在 GitLab 中， 作业也是配置文件中的基本元素. 在 GitLab CI / CD 中，不需要checkout参数，因为系统会自动获取存储库.

CircleCI 示例作业定义：

  1. jobs:
  2.   job1:
  3.     steps:
  4.       - checkout
  5.       - run: "execute-script-for-job1"

GitLab CI / CD 中相同作业定义的示例：

  1. job1:
  2.   script: "execute-script-for-job1"

Docker image definition

CircleCI 在作业级别定义图像，GitLab CI / CD 也支持该图像. 此外，GitLab CI / CD 支持全局设置此设置，以供所有未定义image作业使用.

CircleCI 示例图像定义：

  1. jobs:
  2.   job1:
  3.     docker:
  4.       - image: ruby:2.6

Example of the same image definition in GitLab CI/CD:

  1. job1:
  2.   image: ruby:2.6

Workflows

CircleCI 确定具有workflows作业的运行顺序. 这也可用于确定并发，顺序，计划或手动运行. GitLab CI / CD 中的等效功能称为stage . 同一阶段的作业并行运行，并且仅在先前阶段完成后才运行. 默认情况下，当作业失败时，将跳过下一阶段的执行，但是即使在作业失败之后，也可以继续执行下一阶段.

有关可使用的不同类型的管道的指南，请参见“管道体系结构概述 “. 可以定制管道来满足您的需求，例如大型复杂项目或具有独立定义组件的 monorepo.

Parallel and sequential job execution

以下示例显示了作业如何并行或顺序运行：

  1. job1和job2并行运行（在 GitLab CI / CD 的build阶段）.
  2. 仅在job1和job2成功完成之后（在test阶段）， job1 job3运行.
  3. 仅在job3成功完成之后（在deploy阶段）， job3 job4运行.

CircleCI workflows示例：

  1. version: 2
  2. jobs:
  3.   job1:
  4.     steps:
  5.       - checkout
  6.       - run: make build dependencies
  7.   job2:
  8.     steps:
  9.       - run: make build artifacts
  10.   job3:
  11.     steps:
  12.       - run: make test
  13.   job4:
  14.     steps:
  15.       - run: make deploy
  17. workflows:
  18.   version: 2
  19.   jobs:
  20.     - job1
  21.     - job2
  22.     - job3:
  23.         requires:
  24.           - job1
  25.           - job2
  26.     - job4:
  27.         requires:
  28.           - job3

与 GitLab CI / CD 中的stages相同的工作流程示例：

  1. stages:
  2.   - build
  3.   - test
  4.   - deploy
  6. job 1:
  7.   stage: build
  8.   script: make build dependencies
  10. job 2:
  11.   stage: build
  12.   script: make build artifacts
  14. job3:
  15.   stage: test
  16.   script: make test
  18. job4:
  19.   stage: deploy
  20.   script: make deploy

Scheduled run

GitLab CI / CD 具有易于使用的 UI 来调度管道 . 同样，可以使用规则来确定是否应将作业包括在计划的管道中或从计划的管道中排除.

计划的工作流程的 CircleCI 示例：

  1. commit-workflow:
  2.   jobs:
  3.     - build
  4. scheduled-workflow:
  5.   triggers:
  6.     - schedule:
  7.         cron: "0  1  *  *  *"
  8.         filters:
  9.           branches:
  10.             only: try-schedule-workflow
  11.   jobs:
  12.     - build

使用 GitLab CI / CD 中的rules使用同一调度管道的示例：

  1. job1:
  2.   script:
  3.     - make build
  4.   rules:
  5.     - if: '$CI_PIPELINE_SOURCE  ==  "schedule"  &&  $CI_COMMIT_REF_NAME  ==  "try-schedule-workflow"'

保存管道配置后，您可以在GitLab UI 中配置 cron 计划，并且还可以在 UI 中启用或禁用计划.

Manual run

手动工作流程的 CircleCI 示例：

  1. release-branch-workflow:
  2.   jobs:
  3.     - build
  4.     - testing:
  5.         requires:
  6.           - build
  7.     - deploy:
  8.         type: approval
  9.         requires:
  10.           - testing

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

  1. deploy_prod:
  2.   stage: deploy
  3.   script:
  4.     - echo "Deploy to production server"
  5.   when: manual

Filter job by branch

规则是一种机制，用于确定作业是否将针对特定分支运行.

按分支过滤的作业的 CircleCI 示例：

  1. jobs:
  2.   deploy:
  3.     branches:
  4.       only:
  5.         - master
  6.         - /rc-.*/

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

  1. deploy_prod:
  2.   stage: deploy
  3.   script:
  4.     - echo "Deploy to production server"
  5.   rules:
  6.     - if: '$CI_COMMIT_BRANCH  ==  "master"'

Caching

GitLab 提供了一种缓存机制，可通过重用以前下载的依赖项来加快作业的构建时间. 重要的是要了解缓存和工件之间的区别，以充分利用这些功能.

使用缓存的作业的 CircleCI 示例：

  1. jobs:
  2.   job1:
  3.     steps:
  4.       - restore_cache:
  5.           key: source-v1-< .Revision >
  6.       - checkout
  7.       - run: npm install
  8.       - save_cache:
  9.           key: source-v1-< .Revision >
  10.           paths:
  11.             - "node_modules"

在 GitLab CI / CD 中使用cache的同一管道的示例：

  1. image: node:latest
  3. # Cache modules in between jobs
  4. cache:
  5.   key: $CI_COMMIT_REF_SLUG
  6.   paths:
  7.     - .npm/
  9. before_script:
  10.   - npm ci --cache .npm --prefer-offline
  12. test_async:
  13.   script:
  14.     - node ./specs/start.js ./specs/async.spec.js

Contexts and variables

CircleCI 提供了上下文，以跨项目管道安全地传递环境变量. 在 GitLab 中，可以创建一个组来将相关项目组装在一起. 在组级别， 变量可以存储在各个项目之外，并安全地传递到跨多个项目的管道中.

Orbs

有两个 GitLab 问题需要解决 CircleCI Orb，以及 GitLab 如何实现类似功能.

Build environments

CircleCI 为executors提供executors特定工作的基础技术. 在 GitLab 中，这是由Runners完成的.

支持以下环境：

自我管理的跑步者：

  • Linux
  • Windows
  • macOS

GitLab.com 共享跑步者：

Machine and specific build environments

通过告诉 GitLab 哪些 Runners 应该运行作业， 标签可以用于在不同平台上运行作业.

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

  1. jobs:
  2.   ubuntuJob:
  3.     machine:
  4.       image: ubuntu-1604:201903-01
  5.     steps:
  6.       - checkout
  7.       - run: echo "Hello, $USER!"
  8.   osxJob:
  9.     macos:
  10.       xcode: 11.3.0
  11.     steps:
  12.       - checkout
  13.       - run: echo "Hello, $USER!"

在 GitLab CI / CD 中使用tags进行同一作业的示例：

  1. windows job:
  2.   stage:
  3.     - build
  4.   tags:
  5.     - windows
  6.   script:
  7.     - echo Hello, %USERNAME%!
  9. osx job:
  10.   stage:
  11.     - build
  12.   tags:
  13.     - osx
  14.   script:
  15.     - echo "Hello, $USER!"