• config.yml vs .gitlab-ci.yml
  • Jobs
  • Docker 이미지 정의
  • Workflows
    • 병렬 및 순차 작업 실행
    • 예약 실행
    • 매뉴얼 실행
  • 브랜치별 작업 필터링
  • 캐싱
• 컨텍스트 및 변수
• Orbs
• 빌드 환경
  • 기계 및 특정 빌드 환경

CircleCI에서의 마이그레이션

현재 CircleCI를 사용 중이라면 CI/CD 파이프라인을 GitLab CI/CD로 마이그레이션하여 강력한 기능을 활용할 수 있습니다.

마이그레이션을 시작하기 전에 유용한 여러 자료를 모았습니다.

빠른 시작 가이드는 GitLab CI/CD 작동 방식에 대한 좋은 개요입니다. Auto DevOps도 참고할만 합니다. 이를 사용하면 어떠한 구성도 필요 없이 응용 프로그램을 빌드, 테스트 및 배포할 수 있습니다.

고급 CI/CD 팀을 위해 사용자 정의 프로젝트 템플릿을 사용하여 파이프라인 구성을 재사용할 수 있습니다.

여기서 답변되지 않은 질문이 있다면, GitLab 커뮤니티 포럼이 큰 도움이 될 것입니다.

config.yml vs .gitlab-ci.yml

CircleCI의 config.yml 구성 파일은 스크립트, 작업 및 workflow(이를 GitLab에서는 “stages”라고 함)를 정의합니다. GitLab에서는 해당 리포지터리의 루트 디렉터리에 있는 .gitlab-ci.yml 파일을 사용하여 비슷한 방식을 사용합니다.

Jobs

CircleCI에서 jobs는 특정 작업을 수행하는 단계의 집합입니다. GitLab에서도 jobs은 구성 파일에서 기본 요소입니다. GitLab CI/CD에서는 리포지터리가 자동으로 가져오기 때문에 checkout 키워드는 필요하지 않습니다.

CircleCI의 job 정의 예시:

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

동일한 job 정의의 예시를 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에서의 동등한 기능은 stages라고 합니다. 동일한 stage의 작업은 병렬로 실행되며, 이전 단계가 완료된 후에만 실행됩니다. 기본적으로 job이 실패하면 다음 stage의 실행은 건너뛰지만, 이는 실패한 job 이후에 계속 실행될 수도 있습니다.

사용할 수 있는 다양한 유형의 파이프라인을 위해 파이프라인 아키텍처 개요를 참고하세요. 파이프라인은 크고 복잡한 프로젝트나 독립적으로 정의된 컴포넌트를 가진 monorepo와 같은 여러 요구 사항을 충족시킬 수 있습니다.

병렬 및 순차 작업 실행

다음 예시에서는 작업이 병렬로 실행되거나 순차적으로 실행되는 방법을 보여줍니다:

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

동일한 workflow를 stages로 표현한 GitLab CI/CD에서의 예시:

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는 일정에 따른 파이프라인 실행을 쉽게 할 수 있습니다. 또한, rules을 사용하여 작업이 일정에 포함되거나 제외될지를 결정할 수 있습니다.

CircleCI에서 예약된 workflow의 예시:

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에서 크론 일정을 설정하고, UI에서 일정을 활성화 또는 비활성화할 수 있습니다.

매뉴얼 실행

매뉴얼 workflow의 CircleCI 예시:

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

GitLab CI/CD를 사용하여 동일한 workflow를 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 "배포 작업"
  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:  # 작업 간에 모듈 캐시
    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는 프로젝트 파이프라인 간에 환경 변수를 안전하게 전달하기 위해 컨텍스트를 제공합니다. GitLab에서는 그룹을 만들어 관련 프로젝트를 함께 모을 수 있습니다. 그룹 수준에서는 CI/CD 변수를 개별 프로젝트 외부에 저장하고 여러 프로젝트 간에 파이프라인으로 안전하게 전달할 수 있습니다.

Orbs

GitLab에서는 CircleCI Orbs를 다루는 두 가지 문제가 열려 있으며, GitLab이 유사한 기능을 달성하는 방법을 다룹니다.

• issue #1151
• issue #195173

빌드 환경

CircleCI는 특정 작업을 실행하는 기술로 executors를 제공합니다. GitLab에서는 이를 runners를 통해 수행합니다.

다음 환경이 지원됩니다:

Self-managed runners:

• Linux
• Windows
• macOS

GitLab.com 인스턴스 runners:

• Linux
• Windows (Beta).
• macOS (Beta).

기계 및 특정 빌드 환경

Tags를 사용하여 GitLab에게 작업을 실행할 러너를 지정함으로써 다른 플랫폼에서 작업을 실행할 수 있습니다.

특정 환경에서 작업을 실행하는 작업의 CircleCI 예:

jobs:
  ubuntuJob:
    machine:
      image: ubuntu-1604:201903-01
    steps:
      - checkout
      - run: echo "안녕, $USER!"
  osxJob:
    macos:
      xcode: 11.3.0
    steps:
      - checkout
      - run: echo "안녕하세요, $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!"