CircleCI를 사용하고 있다면 CI/CD 파이프라인을 GitLab CI/CD로 마이그레이션할 수 있습니다. 두 플랫폼 모두 YAML 설정 파일로 파이프라인을 정의하고 스테이지 단위로 job을 실행합니다. 이 때문에 대부분의 CircleCI 개념은 GitLab CI/CD에 직접 대응되는 개념이 있습니다.

config.yml vs .gitlab-ci.yml#

CircleCI의 config.yml 설정 파일은 스크립트, job, 워크플로(GitLab에서는 "stage"라고 함)를 정의합니다. GitLab에서도 이와 비슷한 방식으로, 리포지터리 루트 디렉터리에 있는 .gitlab-ci.yml 파일을 사용합니다.

Jobs#

CircleCI에서 job은 특정 작업을 수행하는 단계(step)의 모음입니다. GitLab에서도 job은 설정 파일의 핵심 요소입니다. GitLab CI/CD에서는 리포지터리를 자동으로 가져오기 때문에 checkout 키워드가 필요하지 않습니다.

CircleCI의 job 정의 예시:

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

GitLab CI/CD에서 동일한 job을 정의한 예시:

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

Docker image definition#

CircleCI는 job 수준에서 이미지를 정의하며, GitLab CI/CD도 이를 지원합니다. 또한 GitLab CI/CD는 image를 정의하지 않은 모든 job에 적용되도록 전역 수준에서 설정하는 것도 지원합니다.

CircleCI의 이미지 정의 예시:

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

GitLab CI/CD에서 동일한 이미지를 정의한 예시:

job1:
  image: ruby:2.6

Workflows#

CircleCI는 workflows를 사용해 job의 실행 순서와 동시 실행 여부, 순차 실행, 예약 실행, 수동 실행 여부를 결정합니다. GitLab CI/CD에서 이에 해당하는 기능은 stage라고 합니다. 같은 stage에 속한 job은 병렬로 실행되며, 이전 stage가 완료된 후에만 실행됩니다. 기본적으로 job 이 실패하면 다음 stage의 실행은 건너뛰지만, job 이 실패한 뒤에도 계속 진행하도록 허용할 수 있습니다.

사용할 수 있는 다양한 유형의 파이프라인에 대한 가이드는 파이프라인 아키텍처 개요를 참고합니다. 파이프라인은 규모가 큰 복잡한 프로젝트나 독립적으로 정의된 컴포넌트로 구성된 모노리포처럼 필요에 맞게 조정할 수 있습니다.

Parallel and sequential job execution#

다음 예시는 job을 병렬 또는 순차적으로 실행하는 방법을 보여줍니다.

1. job1과 job2는 병렬로 실행됩니다(GitLab CI/CD에서는 build stage).
2. job3은 job1과 job2가 모두 성공적으로 완료된 후에만 실행됩니다(test stage).
3. 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

Scheduled run#

GitLab UI에서 cron 일정에 따라 실행되도록 파이프라인을 예약할 수 있습니다. 또한 rules를 사용해 예약된 파이프라인에서 job을 포함하거나 제외할 수도 있습니다.

예약된 워크플로의 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"

파이프라인 설정을 저장한 후 GitLab UI에서 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
  environment: production

Filter job by branch#

Rules는 특정 브랜치에서 job을 실행할지 결정하는 메커니즘입니다.

브랜치별로 필터링된 job의 CircleCI 예시:

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의 빌드 시간을 단축하는 캐싱 메커니즘을 제공합니다. 이 기능을 최대한 활용하려면 캐시와 아티팩트의 차이를 아는 것이 중요합니다.

캐시를 사용하는 job의 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를 사용해 동일한 파이프라인을 정의한 예시:

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 and variables#

CircleCI는 프로젝트 파이프라인 전반에 환경 변수를 안전하게 전달하기 위한 Context를 제공합니다. GitLab에서는 관련된 프로젝트를 모아 그룹을 생성할 수 있습니다. 개별 프로젝트 외부에서 그룹 단위로 CI/CD 변수를 저장하고, 여러 프로젝트에 걸친 파이프라인에 안전하게 전달할 수 있습니다.

Orbs#

CircleCI Orb는 재사용 가능한 CI/CD 설정 패키지입니다. GitLab에서는 CI/CD 컴포넌트가 여러 프로젝트에서 사용할 수 있는 비슷한 재사용 가능한 파이프라인 설정을 제공합니다.

Build environments#

CircleCI는 특정 job을 실행하는 기반 기술로 executor를 제공합니다. GitLab에서는 이를 러너로 수행합니다.

다음 환경을 지원합니다.

셀프 매니지드 러너:

• Linux
• Windows
• macOS

GitLab.com 인스턴스 러너:

• Linux
• Windows (베타)
• macOS (베타)

Machine and specific build environments#

태그를 사용하면 어떤 러너가 job을 실행해야 하는지 GitLab에 알려줌으로써, 서로 다른 플랫폼에서 job을 실행할 수 있습니다.

특정 환경에서 실행되는 job의 CircleCI 예시:

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!"

Related topics#

• GitLab CI/CD 시작하기
• Auto DevOps
• 프로젝트 템플릿