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

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

빠른 시작 가이드는 GitLab CI/CD의 작동 방식에 대한 좋은 개요를 제공합니다. 또한 최소한의 구성으로 애플리케이션을 빌드, 테스트 및 배포하는 데 사용할 수 있는 Auto DevOps에도 관심을 가질 수 있습니다.

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

여기서 답변되지 않은 질문이 있으면 GitLab 커뮤니티 포럼이 훌륭한 리소스가 될 수 있습니다.

config.yml vs .gitlab-ci.yml#

CircleCI의 config.yml 구성 파일은 스크립트, 잡 및 워크플로(GitLab에서는 "스테이지"로 알려짐)를 정의합니다. GitLab에서는 리포지터리의 루트 디렉터리에 있는 .gitlab-ci.yml 파일을 사용하여 유사한 방식을 사용합니다.

잡#

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

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

워크플로#

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

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

병렬 및 순차 잡 실행#

다음 예시는 잡이 병렬로 또는 순차적으로 실행되는 방법을 보여줍니다:

1. job1과 job2는 병렬로 실행됩니다(GitLab CI/CD의 build 스테이지).
2. job3은 job1과 job2가 성공적으로 완료된 후에만 실행됩니다(test 스테이지).
3. 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 CI/CD는 파이프라인 예약을 위한 사용하기 쉬운 UI를 제공합니다. 또한 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에서 크론 스케줄을 구성할 수 있으며, 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:  # 잡 사이에 모듈 캐시
    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와 GitLab이 유사한 기능을 달성하는 방법에 대해 두 가지 GitLab 이슈가 열려 있습니다.

• 이슈 #1151
• 이슈 #195173

빌드 환경#

CircleCI는 특정 잡을 실행하는 기본 기술로 executors를 제공합니다. GitLab에서는 러너를 통해 이를 수행합니다.

지원되는 환경은 다음과 같습니다:

Self-managed 러너:

• Linux
• Windows
• macOS

GitLab.com 인스턴스 러너:

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

머신 및 특정 빌드 환경#

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