Migrating from CircleCI
Migrating from CircleCI
如果您当前正在使用 CircleCI,则可以将 CI / CD 管道迁移到 ,并开始使用其所有强大功能. 查看我们的CircleCI 与 GitLab比较,以了解有什么不同.
在开始迁移之前,我们已经收集了一些您可能会觉得有用的资源.
很好地概述了 GitLab CI / CD 的工作方式. 您可能还对Auto DevOps感兴趣,可以将其用于构建,测试和部署应用程序,而几乎不需要或根本不需要进行任何配置.
对于高级 CI / CD 团队, 可以启用管道配置的重用.
如果您有未在此处回答的问题, GitLab 社区论坛将是一个很好的资源.
CircleCI 的config.yml
配置文件定义了脚本,作业和工作流程(在 GitLab 中称为”阶段”). 在 GitLab 中,对存储库根目录中的.gitlab-ci.yml
文件使用类似的方法.
在 CircleCI 中,作业是执行特定任务的步骤的集合. 在 GitLab 中, 也是配置文件中的基本元素. 在 GitLab CI / CD 中,不需要checkout
参数,因为系统会自动获取存储库.
CircleCI 示例作业定义:
GitLab CI / CD 中相同作业定义的示例:
job1:
script: "execute-script-for-job1"
Docker image definition
CircleCI 在作业级别定义图像,GitLab CI / CD 也支持该图像. 此外,GitLab CI / CD 支持全局设置此设置,以供所有未定义image
作业使用.
CircleCI 示例图像定义:
jobs:
job1:
docker:
- image: ruby:2.6
Example of the same image definition in GitLab CI/CD:
job1:
image: ruby:2.6
有关可使用的不同类型的管道的指南,请参见 “. 可以定制管道来满足您的需求,例如大型复杂项目或具有独立定义组件的 monorepo.
Parallel and sequential job execution
以下示例显示了作业如何并行或顺序运行:
job1
和job2
并行运行(在 GitLab CI / CD 的build
阶段).- 仅在
job1
和job2
成功完成之后(在test
阶段),job1
job3
运行. - 仅在
job3
成功完成之后(在deploy
阶段),job3
job4
运行.
CircleCI workflows
示例:
version: 2
jobs:
job1:
steps:
- checkout
- run: make build dependencies
job2:
steps:
- run: make build artifacts
job3:
steps:
job4:
steps:
- run: make deploy
version: 2
jobs:
- job1
- job2
- job3:
requires:
- job1
- job2
- job4:
requires:
- job3
与 GitLab CI / CD 中的stages
相同的工作流程示例:
Scheduled run
GitLab CI / CD 具有易于使用的 UI 来调度管道 . 同样,可以使用来确定是否应将作业包括在计划的管道中或从计划的管道中排除.
计划的工作流程的 CircleCI 示例:
commit-workflow:
jobs:
- build
scheduled-workflow:
triggers:
- schedule:
cron: "0 1 * * *"
filters:
branches:
only: try-schedule-workflow
jobs:
- build
使用 GitLab CI / CD 中的rules
使用同一调度管道的示例:
job1:
script:
- make build
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == "try-schedule-workflow"'
保存管道配置后,您可以在配置 cron 计划,并且还可以在 UI 中启用或禁用计划.
Manual run
手动工作流程的 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
Filter job by branch
规则是一种机制,用于确定作业是否将针对特定分支运行.
按分支过滤的作业的 CircleCI 示例:
deploy_prod:
script:
- echo "Deploy to production server"
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
GitLab 提供了一种缓存机制,可通过重用以前下载的依赖项来加快作业的构建时间. 重要的是要了解之间的区别,以充分利用这些功能.
使用缓存的作业的 CircleCI 示例:
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
的同一管道的示例:
image: node:latest
# Cache modules in between jobs
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- .npm/
before_script:
- npm ci --cache .npm --prefer-offline
test_async:
script:
- node ./specs/start.js ./specs/async.spec.js
CircleCI 提供了上下文,以跨项目管道安全地传递环境变量. 在 GitLab 中,可以创建一个来将相关项目组装在一起. 在组级别, 变量可以存储在各个项目之外,并安全地传递到跨多个项目的管道中.
有两个 GitLab 问题需要解决 CircleCI Orb,以及 GitLab 如何实现类似功能.
CircleCI 为executors
提供executors
特定工作的基础技术. 在 GitLab 中,这是由完成的.
支持以下环境:
自我管理的跑步者:
- Linux
- Windows
- macOS
GitLab.com 共享跑步者:
- Linux
- Windows
- Planned: macOS
Machine and specific build environments
通过告诉 GitLab 哪些 Runners 应该运行作业, 标签可以用于在不同平台上运行作业.
在特定环境中运行的作业的 CircleCI 示例:
jobs:
ubuntuJob:
machine:
image: ubuntu-1604:201903-01
steps:
- checkout
- run: echo "Hello, $USER!"
osxJob:
macos:
xcode: 11.3.0
steps:
- checkout
在 GitLab CI / CD 中使用进行同一作业的示例: