• config.yml 대 .gitlab-ci.yml
  • 작업
  • 도커 이미지 정의
  • 워크플로우
    • 병렬 및 순차 작업 실행
    • 예약된 실행
    • 수동 실행
  • 브랜치로 작업 필터링
  • 캐싱
• 컨텍스트와 변수
• Orbs
• 빌드 환경
  • 머신 및 특정 빌드 환경

CircleCI에서의 마이그레이션

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

마이그레이션을 시작하기 전에 유용할 수 있는 여러 자원을 수집했습니다.

빠른 시작 가이드는 GitLab CI/CD 작동 방식에 대한 좋은 개요입니다. Auto DevOps도 관심이 있을 것인데, 거의 또는 전혀 구성할 필요 없이 응용 프로그램을 빌드, 테스트 및 배포하는 데 사용할 수 있습니다.

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

여기에서 답변되지 않은 질문이 있다면 GitLab 커뮤니티 포럼도 훌륭한 자원이 될 수 있습니다.

config.yml 대 .gitlab-ci.yml

CircleCI의 config.yml 구성 파일은 스크립트, 작업 및 워크플로우 (GitLab의 “단계”로 알려진)를 정의합니다. GitLab에서는 리포지토리의 루트 디렉터리에 있는 .gitlab-ci.yml 파일을 사용하여 비슷한 방식을 사용합니다.

작업

CircleCI에서 작업은 특정 작업을 수행하는 일련의 단계입니다. GitLab에서도 구성 파일의 기본 요소로 작업이 사용됩니다. GitLab CI/CD에서는 저장소가 자동으로 가져오기 때문에 checkout 키워드는 필요하지 않습니다.

CircleCI의 예시 작업 정의:

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

GitLab CI/CD의 동일한 작업 정의 예시:

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

도커 이미지 정의

CircleCI는 작업 수준에서 이미지를 정의하며, 이는 GitLab CI/CD에서도 지원됩니다. 추가로, GitLab CI/CD는 모든 작업에서 사용할 수 있도록 전역적으로 이를 설정할 수 있습니다.

CircleCI의 예시 이미지 정의:

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

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

job1:
  image: ruby:2.6

워크플로우

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

사용할 수 있는 다양한 종류의 파이프라인에 대한 지침은 파이프라인 아키텍처 개요를 참조하세요. 파이프라인은 대규모 복잡한 프로젝트나 독립적으로 정의된 구성 요소를 갖는 단일 저장소 등과 같이 필요에 맞게 맞춰질 수 있습니다.

병렬 및 순차 작업 실행

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

1. job1과 job2는 병렬로 실행됨 (build 단계에서 GitLab CI/CD).
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:
  - 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는 파이프라인 예약을 사용하기 쉬우며, 규칙은 작업이 예약된 파이프라인에 포함되거나 제외될지를 결정하는 데 사용할 수 있습니다.

예시로서 규칙을 사용한 GitLab CI/CD에서 같은 예약된 파이프라인:

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

when: manual을 사용한 GitLab CI/CD의 동일한 워크플로우 예시:

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

CircleCI Orbs를 다룬 두 개의 GitLab 이슈와 GitLab이 유사한 기능을 어떻게 달성할 수 있는지에 대한 내용입니다.

• 이슈 #1151
• 이슈 #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 "안녕, $USER!"