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

CircleCI에서 GitLab으로 마이그레이션

현재 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"  

도커 이미지 정의

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

사용할 수 있는 다양한 유형의 파이프라인에 대한 안내는 파이프라인 아키텍처 개요를 참조하십시오. 파이프라인은 대형 복잡한 프로젝트나 독립적으로 정의된 구성 요소가 있는 모노레포에 맞게 조정할 수 있습니다.

병렬 및 순차적 작업 실행

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

1. job1과 job2는 병렬로 실행됩니다(기본 GitLab CI/CD의 build 단계에서).
2. job3는 job1과 job2가 성공적으로 완료된 후에만 실행됩니다(기본 GitLab CI/CD의 test 단계에서).
3. job4는 job3가 성공적으로 완료된 후에만 실행됩니다(기본 GitLab CI/CD의 deploy 단계에서).

CircleCI에서의 workflows 예:

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에서 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 "생산 서버에 배포"
  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은 이전에 다운로드된 종속성을 재사용하여 작업의 빌드 시간을 단축하는 캐싱 메커니즘을 제공합니다. 이러한 기능을 최적으로 활용하기 위해 cache와 artifacts의 차이를 아는 것이 중요합니다.

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에서는 관련 프로젝트를 함께 모으기 위해 Group 을 생성할 수 있습니다. 그룹 수준에서, CI/CD 변수는 개별 프로젝트 외부에 저장되고 여러 프로젝트에 걸쳐 파이프라인으로 안전하게 전달될 수 있습니다.

Orbs

GitLab에서 CircleCI Orbs와 유사한 기능을 어떻게 구현할 수 있는지에 대한 두 가지 문제가 열려 있습니다.

• issue #1151
• issue #195173

빌드 환경

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

다음 환경이 지원됩니다:

자체 관리 러너:

• 리눅스
• 윈도우
• macOS

GitLab.com 인스턴스 러너:

• 리눅스
• 윈도우 (beta).
• macOS (beta).

기계 및 특정 빌드 환경

태그를 사용하여 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!"