• 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 구성 파일은 스크립트, 작업 및 workflows(여기서는 GitLab의 “stages”로 알려짐)을 정의합니다. GitLab에서는 .gitlab-ci.yml 파일이 사용되어 같은 접근 방식을 사용합니다. 귀하의 저장소 루트 디렉터리에 있습니다.

Jobs

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

CircleCI 예시 job 정의:

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

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

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

Docker 이미지 정의

CircleCI에서는 이미지를 job 레벨에서 정의하는데, 이는 GitLab CI/CD에서도 지원됩니다. 추가로, GitLab CI/CD는 모든 job이 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의 작업은 병렬로 실행되며, 이전 stage가 완료된 후에만 실행됩니다. 기본적으로 작업이 실패하면 다음 stage의 실행이 건너뛰지만, 실패한 작업 이후에도 계속 실행될 수 있습니다.

사용할 수 있는 다양한 종류의 파이프라인을 위한 파이프라인 아키텍처 개요를 참조하세요. 파이프라인은 대규모 복잡한 프로젝트나 독립적으로 정의된 구성 요소를 가진 단일 저장소와 같이 필요에 맞게 맞춤화될 수 있습니다.

병렬 및 순차 작업 실행

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

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로 표현된 동일한 workflow의 예시:

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에는 파이프라인 예약을 위한 사용하기 쉬운 UI가 있습니다. 또한, rules은 작업을 예약된 파이프라인에 포함하거나 제외할지를 결정하는 데 사용될 수 있습니다.

예약된 workflow를 위한 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에서 크론 일정을 구성하고 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 "프로덕션 서버로 배포"
  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이 유사한 기능을 달성하는 방법에 대한 두 가지 문제가 열려 있습니다.

• 이슈 #1151
• 이슈 #195173

빌드 환경

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

다음 환경이 지원됩니다:

셀프매니지드 러너:

• 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 "안녕, $USER!"
  osxJob:
    macos:
      xcode: 11.3.0
    steps:
      - checkout
      - run: echo "안녕, $USER!"

GitLab CI/CD에서 tags를 사용한 동일한 작업의 예시:

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

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