CircleCI에서 마이그레이션하기

CircleCI에서 마이그레이션하기 (Migrate from CircleCI)

CircleCI를 사용한다면 CI/CD 파이프라인을 GitLab CI/CD로 마이그레이션할 수 있어요. 두 플랫폼 모두 YAML 설정 파일로 파이프라인을 정의하고 잡을 스테이지 단위로 실행해요. 그래서 대부분의 CircleCI 개념은 GitLab CI/CD에 직접적인 대응물이 있어요.

출처: 문서

본문

`config.yml` vs `.gitlab-ci.yml`

CircleCI의 config.yml 설정 파일은 스크립트, 잡, 워크플로우(GitLab에서는 "스테이지")를 정의해요. GitLab에서는 저장소 루트 디렉터리의 .gitlab-ci.yml 파일로 비슷한 방식을 사용해요.

잡 (Jobs)

CircleCI에서 잡은 특정 태스크를 수행하는 단계(step)의 모음이에요. GitLab에서 잡도 설정 파일의 기본 요소예요. 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로 잡의 실행 순서와 실행 방식(병렬·순차·예약·수동)을 결정해요. GitLab CI/CD에서 이에 해당하는 기능은 스테이지예요. 같은 스테이지의 잡은 병렬로 실행되고 이전 스테이지가 끝난 후에만 실행돼요. 기본적으로 잡이 실패하면 다음 스테이지 실행은 건너뛰지만, 실패한 잡 이후에도 계속 진행되도록 허용할 수 있어요.

사용할 수 있는 다양한 파이프라인 유형에 대한 지침은 파이프라인 아키텍처 개요를 참고하세요. 대규모 복잡 프로젝트나 독립적으로 정의된 컴포넌트가 있는 모노레포처럼 필요에 맞게 파이프라인을 조정할 수 있어요.

병렬 및 순차 잡 실행

다음 예시들은 잡이 병렬 또는 순차로 실행되는 방법을 보여줘요:

job1과 job2는 병렬로 실행돼요(GitLab CI/CD에서는 build 스테이지).
job3은 job1과 job2가 성공적으로 완료된 후에만 실행돼요(test 스테이지).
job4는 job3이 성공적으로 완료된 후에만 실행돼요(deploy 스테이지).

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 UI에서 cron 일정으로 파이프라인을 예약할 수 있어요. rules로 예약 파이프라인에서 잡을 포함하거나 제외할 수도 있어요.

예약 워크플로우의 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에서 일정을 활성화하거나 비활성화할 수도 있어요.

수동 실행

수동 워크플로우의 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는 특정 브랜치에 대해 잡이 실행될지 결정하는 메커니즘이에요.

브랜치로 필터링된 잡의 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

캐싱

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를 사용한 같은 파이프라인의 예시:

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

컨텍스트와 변수

CircleCI는 프로젝트 파이프라인 간에 환경 변수를 안전하게 전달하는 Contexts를 제공해요. GitLab에서는 관련 프로젝트를 묶기 위해 그룹을 만들 수 있어요. CI/CD 변수를 개별 프로젝트 밖의 그룹에 저장하고, 여러 프로젝트의 파이프라인에 안전하게 전달할 수 있어요.

Orbs

CircleCI Orbs는 CI/CD 구성의 재사용 가능한 패키지예요. GitLab에서는 CI/CD 컴포넌트가 프로젝트 간에 사용할 수 있는 유사한 재사용 파이프라인 구성을 제공해요.

빌드 환경

CircleCI는 특정 잡을 실행하기 위한 기반 기술로 executors를 제공해요. GitLab에서는 이를 러너로 처리해요.

다음 환경이 지원돼요:

Self-managed 러너:

Linux
Windows
macOS

GitLab.com 인스턴스 러너:

Linux
Windows (beta).
macOS (beta).

머신 및 특정 빌드 환경

tags를 사용해 어떤 러너가 잡을 실행해야 하는지 GitLab에 알려서 잡을 다른 플랫폼에서 실행할 수 있어요.

특정 환경에서 실행되는 잡의 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를 사용한 같은 잡의 예시:

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

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

더 알아보기

다음으로는 GitLab CI/CD 시작하기 가이드를 따라 첫 파이프라인을 만들어보고, CI/CD 컴포넌트 문서를 읽으면 워크플로우를 재사용 가능한 구성으로 정리하는 방법을 익힐 수 있어요.

CircleCI에서 마이그레이션하기