100===Dev Ops/Git

GitLab CICD로 쉽고 강력한 자동화 파이프라인 구축하기 🚀

블로글러 2024. 6. 11. 23:34

요약: GitLab CI/CD는 코드 저장소와 통합된 내장형 자동화 도구로, .gitlab-ci.yml 파일 하나로 전체 소프트웨어 개발 파이프라인을 정의하고 실행할 수 있습니다. 빌드, 테스트, 배포를 자동화하여 개발 효율성을 높이고 지속적인 품질 유지가 가능합니다. 이 글에서는 GitLab CI/CD의 기본 개념부터 실제 구성 방법, 최적화 전략까지 단계별로 설명합니다.

GitLab CI/CD가 뭔가요? 🤔

여러분의 소프트웨어 개발 과정을 자동화된 조립 라인처럼 상상해보세요.

  • 개발자가 만든 코드가
  • 자동으로 테스트되고, 빌드되고, 배포되는 과정

GitLab CI/CD는 바로 이런 자동화된 파이프라인을 쉽게 구축할 수 있게 해주는 도구입니다!

  • CI(Continuous Integration): 코드 변경사항을 자동으로 통합하고 테스트하는 과정
  • CD(Continuous Delivery/Deployment): 검증된 코드를 자동으로 배포하는 과정

마치 레고 블록처럼 각 단계를 조립해 전체 개발 프로세스를 자동화할 수 있습니다 ✨

어떻게 구성하나요? 🎬

1. 기본 설정 - .gitlab-ci.yml

GitLab CI/CD의 모든 것은 프로젝트 루트 디렉토리에 위치한 .gitlab-ci.yml 파일로 시작합니다.

# 가장 기본적인 CI/CD 파이프라인 구성
stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "애플리케이션을 빌드합니다..."
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

test_job:
  stage: test
  script:
    - echo "테스트를 실행합니다..."
    - npm test

deploy_job:
  stage: deploy
  script:
    - echo "애플리케이션을 배포합니다..."
  environment:
    name: production
  only:
    - master

2. GitLab Runner 설정하기

GitLab Runner는 CI/CD 작업을 실행하는 에이전트입니다. 프로젝트에 러너를 등록하는 방법:

  1. GitLab 관리자에게 공유 러너 사용 권한을 요청하거나
  2. 자체 러너를 설치하고 등록:
# 1. 러너 설치 (예: Ubuntu)
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-runner

# 2. 러너 등록
sudo gitlab-runner register

등록 과정에서 다음 정보를 입력합니다:

  • GitLab URL
  • 등록 토큰 (프로젝트 설정 → CI/CD → Runners)
  • 설명 및 태그
  • Executor 유형 (Docker, Shell 등)

3. 파이프라인 구성 요소 상세 설명

a. 스테이지(Stages)

파이프라인의 각 단계를 정의합니다. 각 스테이지는 순차적으로 실행됩니다.

stages:
  - build      # 1단계
  - test       # 2단계
  - deploy_staging  # 3단계
  - deploy_production # 4단계

b. 작업(Jobs)

각 스테이지에서 실행되는 실제 작업입니다. 같은 스테이지의 작업들은 병렬로 실행됩니다.

build_frontend:
  stage: build
  script:
    - cd frontend
    - npm install
    - npm run build

build_backend:
  stage: build
  script:
    - cd backend
    - mvn package

c. 스크립트(Script)

각 작업에서 실행되는 실제 명령어 목록입니다.

test_unit:
  stage: test
  script:
    - npm run test:unit
    - echo "단위 테스트 완료!"

d. 아티팩트(Artifacts)

작업의 결과물로, 다른 작업이나 수동 다운로드에 사용할 수 있습니다.

build_app:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week  # 1주일 후 자동 삭제

e. 환경 변수 및 비밀 설정

variables:
  # 일반 변수
  NODE_ENV: production

deploy_production:
  stage: deploy
  script:
    # 보안 변수 사용 (GitLab UI에서 설정)
    - echo $API_TOKEN  # 실제 값은 로그에 표시되지 않음
    - deploy-script --token $API_TOKEN

동작 방식 💫

마치 자동화된 공장처럼 작동합니다!

  1. 개발자가 코드를 푸시하면
  2. 개발자: "새로운 기능 개발 완료! master 브랜치에 푸시합니다."
  3. GitLab CI/CD가 이를 감지하고 파이프라인 시작
  4. GitLab: "변경 감지! CI/CD 파이프라인을 시작합니다."
  5. 설정된 순서에 따라 자동으로 단계 실행
  6. GitLab Runner: "빌드 중... 테스트 중... 배포 중..."
  7. 각 단계의 결과를 보고
  8. GitLab: "파이프라인 성공! 모든 단계가 통과되었습니다."

고급 구성 예시 🔧

1. 조건부 실행

특정 조건에서만 작업을 실행할 수 있습니다:

deploy_production:
  stage: deploy
  script:
    - echo "프로덕션 환경에 배포합니다..."
  only:
    - master  # master 브랜치에만 실행
  when: manual  # 수동 승인 후 실행

2. 병렬 실행 최적화

테스트를 병렬화하여 실행 시간을 단축할 수 있습니다:

test:
  stage: test
  parallel: 3  # 3개의 병렬 작업으로 분할
  script:
    - npm test -- --split=3 --part=$CI_NODE_INDEX

3. 캐시를 활용한 빌드 속도 향상

의존성을 캐싱하여 빌드 시간을 단축할 수 있습니다:

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .npm/

4. 다중 환경 배포

개발, 스테이징, 프로덕션 등 여러 환경에 배포할 수 있습니다:

deploy_dev:
  stage: deploy
  script:
    - deploy-to-dev-server
  environment:
    name: development
    url: https://dev.example.com
  only:
    - develop

deploy_prod:
  stage: deploy
  script:
    - deploy-to-prod-server
  environment:
    name: production
    url: https://example.com
  only:
    - master
  when: manual

GitLab CI/CD의 장점 🌟

  1. 내장형 솔루션
    • 별도의 Jenkins나 CircleCI 같은 외부 도구 불필요
    • GitLab 저장소와 완벽하게 통합
  2. 간편한 설정
    • YAML 파일 하나로 전체 파이프라인 정의
    • 직관적인 구성으로 빠른 시작 가능
  3. 자동화된 워크플로우
    • 코드 변경 시 자동으로 전체 과정 실행
    • 인적 오류 감소 및 일관된 품질 유지
  4. 확장성
    • 간단한 애플리케이션부터 복잡한 마이크로서비스까지 지원
    • 다양한 언어 및 프레임워크 대응
  5. 모니터링 및 가시성
    • 파이프라인 상태를 실시간으로 확인
    • 문제 발생 시 빠른 대응 가능

주의할 점 ⚠️

  1. 리소스 관리
    • 너무 많은 작업을 동시에 실행하면 러너에 부하
    • 적절한 캐싱 전략으로 빌드 시간 최적화 필요
  2. 보안 관리
    • API 토큰, 비밀번호 등은 반드시 보안 변수로 관리
    • .gitlab-ci.yml에 직접 하드코딩하지 말 것
  3. 복잡성 관리
    • 너무 복잡한 파이프라인은 유지보수 어려움
    • include 기능으로 구성 파일 모듈화 권장
  4. 테스트 품질
    • 자동화된 테스트의 품질이 CI/CD 효과 결정
    • 적절한 테스트 커버리지 유지 필요

실제 사용 예시 - 웹 애플리케이션 CI/CD 📱

# 전체 웹 애플리케이션 CI/CD 파이프라인 예시
stages:
  - build
  - test
  - security
  - deploy_staging
  - deploy_production

variables:
  NODE_ENV: production

# 의존성 캐싱
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

# 프론트엔드 빌드
build_frontend:
  stage: build
  image: node:16
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

# 단위 테스트
unit_test:
  stage: test
  image: node:16
  script:
    - npm ci
    - npm run test:unit
  coverage: '/전체 커버리지: (\d+\.\d+)%/'

# 통합 테스트
integration_test:
  stage: test
  image: cypress/browsers:node16-chrome100
  script:
    - npm ci
    - npm run test:integration

# 보안 스캔
security_scan:
  stage: security
  image: owasp/zap2docker-stable
  script:
    - zap-baseline.py -t https://staging.example.com || true
  allow_failure: true

# 스테이징 배포
deploy_staging:
  stage: deploy_staging
  image: alpine:latest
  before_script:
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
  script:
    - rsync -avz -e "ssh -o StrictHostKeyChecking=no" dist/ user@staging-server:/var/www/app/
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

# 프로덕션 배포 (수동 승인 필요)
deploy_production:
  stage: deploy_production
  image: alpine:latest
  before_script:
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
  script:
    - rsync -avz -e "ssh -o StrictHostKeyChecking=no" dist/ user@production-server:/var/www/app/
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - master

Auto DevOps로 더 쉽게 시작하기 🛠️

GitLab Auto DevOps를 사용하면 .gitlab-ci.yml 파일 없이도 CI/CD 파이프라인을 자동으로 구성할 수 있습니다:

  1. 프로젝트 설정 → CI/CD → Auto DevOps로 이동
  2. "Default to Auto DevOps pipeline" 활성화
  3. 자동으로 빌드, 테스트, 코드 품질 검사, 보안 스캔, 배포까지 진행

특정 언어나 프레임워크를 자동으로 감지하여 적절한 파이프라인을 구성해줍니다!

마치며 🎁

GitLab CI/CD는 개발 프로세스를 자동화하는 강력한 도구입니다. 간단한 YAML 파일 하나로 복잡한 개발 파이프라인을 구축할 수 있으며, 코드 품질을 일관되게 유지하고 배포 프로세스를 가속화할 수 있습니다.

이제 GitLab CI/CD로 자동화의 힘을 경험해보세요. 개발자는 코드에만 집중하고, 나머지는 자동화된 파이프라인이 처리하도록 맡겨보세요!


참고자료

  1. GitLab 공식 CI/CD 문서: GitLab CI/CD Documentation^1^
  2. GitLab CI/CD 모범 사례: CI/CD Best Practices^2^
  3. GitLab Runner 설치 가이드: Runner Installation^3^
  4. GitLab CI/CD YAML 구문: GitLab CI/CD YAML Syntax^4^
  5. GitLab CI/CD 고급 사용법: Advanced CI/CD Usage^5^
  6. GitLab Auto DevOps: Auto DevOps^6^
728x90