CircleCI에서 마이그레이션
현재 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-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는 전역적으로 image가 정의되지 않은 모든 작업에서 사용할 수 있습니다.
CircleCI 예시 이미지 정의:
jobs:
job1:
docker:
- image: ruby:2.6
GitLab CI/CD에서 동일한 이미지 정의 예시:
job1:
image: ruby:2.6
워크플로우
CircleCI는 workflows로 작업의 실행 순서를 결정합니다. 이는 동시, 순차, 예약 또는 매뉴얼 실행을 결정하는 데 사용됩니다. GitLab CI/CD의 동등한 기능은 stages라고 합니다. 동일한 스테이지에 있는 작업은 병렬로 실행되며, 이전 스테이지가 완료된 후에만 실행됩니다. 기본적으로 작업이 실패하면 다음 스테이지의 실행이 건너뛰지만, 실패한 작업 이후에도 계속 실행되도록 허용할 수 있습니다.
사용할 수 있는 다양한 유형의 파이프라인에 대한 안내는 파이프라인 아키텍처 개요에서 확인할 수 있습니다. 파이프라인은 고대로 사용하거나 큰 복잡한 프로젝트나 독립적으로 정의된 컴포넌트가 있는 모노 레포와 같은 여러 요구 사항을 충족시키도록 맞춤화할 수 있습니다.
병렬 및 순차 작업 실행
다음 예시에서 작업이 병렬로 실행되거나 순차적으로 실행되는 방법을 보여줍니다:
-
job1및job2는 병렬로 실행됩니다 (GitLab CI/CD의build스테이지에서 실행). -
job3은job1과job2가 성공적으로 완료된 후에만 실행됩니다 (test스테이지에서 실행). -
job4는job3이 성공적으로 완료된 후에만 실행됩니다 (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은 이전에 다운로드한 의존성을 재사용하여 작업의 빌드 시간을 단축하는 캐싱 메커니즘을 제공합니다. 이러한 기능을 최대한 활용하기 위해 캐시와 아티팩트의 차이를 알아두는 것이 중요합니다.
캐시를 사용하는 CircleCI 작업의 예시:
jobs:
job1:
steps:
- restore_cache:
key: source-v1-< .Revision >
- checkout
- run: npm install
- save_cache:
key: source-v1-< .Revision >
paths:
- "node_modules"
동일한 파이프라인을 cache를 사용하여 구성한 GitLab CI/CD 예시:
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 변수를 개별 프로젝트 외부에 저장하고, 여러 프로젝트에 걸쳐 파이프라인으로 안전하게 전달할 수 있습니다.
오브
CircleCI 오브에 대한 두 가지 GitLab 이슈가 열려 있으며, GitLab이 유사한 기능을 어떻게 구현할 수 있는지에 대해 다룹니다.
빌드 환경
CircleCI는 특정 작업을 실행하는 기술로 executors를 제공합니다. GitLab에서는 이를 러너로 수행합니다.
다음 환경이 지원됩니다:
Self-Managed형 러너:
- Linux
- Windows
- macOS
GitLab.com 인스턴스 러너:
기계 및 특정 빌드 환경
태그를 사용하여 GitLab에게 어떤 러너가 작업을 실행해야 하는지 알려주어 다른 플랫폼에서 작업을 실행할 수 있습니다.
특정 환경에서 작업을 실행하는 CircleCI의 예시:
작업:
Ubuntu작업:
기계:
이미지: ubuntu-1604:201903-01
스텝들:
- 체크아웃
- 실행: echo "안녕하세요, $USER!"
osxJob:
macos:
xcode: 11.3.0
단계:
- 체크아웃
- 실행: echo "안녕하세요, $USER!"
GitLab CI/CD에서 태그를 사용하여 동일한 작업의 예시:
윈도우 작업:
스테이지: 빌드
태그:
- 윈도우
스크립트:
- echo Hello, %USERNAME%!
osx 작업:
스테이지: 빌드
태그:
- osx
스크립트:
- echo "안녕하세요, $USER!"
도움말