GitLab CI/CD

GitLab CI/CD는 이 플랫폼의 가장 강력한 차별점입니다. 저장소 루트에 .gitlab-ci.yml 파일 하나를 두면, 코드를 push할 때마다 GitLab이 자동으로 빌드하고 테스트하고 배포하는 파이프라인을 실행합니다. 별도 CI 서비스를 붙일 필요가 없습니다.

학습 목표

• .gitlab-ci.yml로 파이프라인을 정의하는 방법을 이해한다.
• pipeline, stage, job의 관계를 구분한다.
• GitLab Runner가 무엇이며 어떻게 작업을 실행하는지 안다.
• 빌드·테스트·배포로 이어지는 간단한 파이프라인을 작성한다.

pipeline, stage, job

CI/CD 구조는 세 단어로 정리됩니다.

• Pipeline: 한 번의 실행 전체. 보통 push나 MR마다 만들어진다.
• Stage: 파이프라인 안의 단계(예: build, test, deploy). stage는 순서대로 실행된다.
• Job: stage 안에서 실제로 실행되는 작업. 같은 stage의 job들은 병렬로 실행된다.

즉 파이프라인은 여러 stage로 나뉘고, 각 stage는 여러 job을 담습니다. 앞 stage의 job이 모두 성공해야 다음 stage로 넘어갑니다.

GitLab Runner

job을 실제로 실행하는 주체가 GitLab Runner입니다. GitLab 서버는 "무엇을 할지" 지시하고, Runner라는 별도 프로그램이 그 명령을 받아 실행합니다.

Runner는 연결 범위에 따라 세 가지로 나뉩니다(예전 명칭은 괄호 안).

• Instance runner(옛 Shared): gitlab.com이 제공하는 공용 실행 환경. 가입 후 바로 쓸 수 있다.
• Group runner: 특정 그룹의 모든 프로젝트가 함께 쓰도록 연결한 Runner.
• Project runner(옛 Specific): 특정 프로젝트에만 연결한 전용 Runner. self-hosted 환경에서 직접 설치해 쓴다.

Runner는 보통 Docker 이미지 안에서 job을 실행하므로, job마다 필요한 환경(예: Node, Python 버전)을 이미지로 지정할 수 있습니다.

첫 .gitlab-ci.yml

가장 단순한 형태부터 봅니다. stage를 선언하고, 각 job이 어느 stage에 속하는지와 실행할 명령을 적습니다.

stages:
  - build
  - test

build-job:
  stage: build
  script:
    - echo "빌드 시작"
    - npm ci
    - npm run build

test-job:
  stage: test
  script:
    - npm test

이 파일을 저장소 루트에 두고 push하면, build 단계가 끝난 뒤 test 단계가 실행됩니다.

빌드·테스트·배포 예시

조금 더 실용적인 예시입니다. 이미지를 지정하고, 의존성을 캐시하고, 특정 브랜치에서만 배포하도록 규칙을 둡니다.

image: node:20

stages:
  - build
  - test
  - deploy

cache:
  paths:
    - node_modules/

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - npm test

deploy:
  stage: deploy
  script:
    - echo "프로덕션 배포"
    - ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

핵심 키워드를 정리합니다.

• image: job을 실행할 Docker 이미지
• script: 실제로 실행할 셸 명령 목록
• artifacts: job 결과물(예: 빌드 산출물)을 다음 stage로 전달
• cache: 실행 간 재사용할 디렉터리(의존성 등)로 속도 향상
• rules: job을 언제 실행할지 조건 지정(여기서는 main 브랜치에서만 배포)

$CI_COMMIT_BRANCH 같은 변수는 GitLab이 자동으로 제공하는 미리 정의된 CI/CD 변수입니다. 비밀 값(토큰, 키)은 파일에 직접 쓰지 말고 프로젝트 Settings > CI/CD > Variables에 등록해 사용합니다.

파이프라인 확인

push하면 프로젝트의 Build > Pipelines(또는 MR 화면)에서 진행 상황을 볼 수 있습니다. 각 job의 로그를 열어 실패 원인을 확인하고, 실패한 job만 다시 실행할 수도 있습니다. MR 화면에서는 파이프라인이 통과해야만 머지하도록 막는 설정도 가능합니다.

요약

GitLab CI/CD는 .gitlab-ci.yml 한 파일로 파이프라인을 정의합니다. 파이프라인은 순서대로 도는 stage로 나뉘고, 각 stage는 병렬 실행되는 job을 담습니다. job은 GitLab Runner가 보통 Docker 이미지 안에서 실행하며, image·script·artifacts·cache·rules 같은 키워드로 빌드·테스트·배포를 구성합니다. 비밀 값은 CI/CD Variables로 안전하게 관리합니다. 다음 강의에서는 작업을 추적하는 이슈와 보드를 다룹니다.