GitLab CI/CD를 통한 배포 자동화

1. CI/CD란?

1. CI (Continuous Integration) : 지속적 통합

지속적인 통합이라는 의미로 제품(애플리케이션 코드)의 새로운 변경 사항이나 추가적인 사항을 정기적으로 빌드 및 테스트가 되어 최종 형상으로 병합하는 과정을 의미합니다.

 

CI의 핵심 목표는 버그를 신속하게 찾고, 소프트웨어의 품질을 개선 및 관리하며, 릴리즈의 시간을 단축하는것에 의미가 있습니다.

 

개발자들이 각자 작업한 코드를 정기적으로 공통 저장소에 모으고, 자동으로 빌드 및 테스트하는 과정입니다.

• 배경 : 여러 명의 개발자가 동시에 같은 프로젝트를 작업하면, 나중에 코드를 합칠 때 충돌(Conflict)이 발생하기 쉽습니다.
• 핵심 과정 :
  • 개발자가 코드를 코드 저장소(Gibhub 등)에 올립니다.
  • 자동화된 툴이 코드를 가져와서 **빌드(Build)** 합니다.
  • 작성된 테스트 코드를 실행하여 버그가 없는지 확인합니다.
• 장점 : 버그를 아주 빠르게 발견할 수 있고, 로컬에서는 성공하는데 서버에서 실패하는 상황을 사전에 방지 합니다.

2. CD(Continuous Delivery / Deployment ) : 지속적 제공 및 배포

CI 과정을 거친 코드를 실제 서비스 환경에 자동으로 반영하는 단계 입니다. 여기서 CD는 두 가지 의미를 포함 합니다.

• 지속적 제공 (Continuous Delivery) : 빌드와 테스트가 완료된 코드를 배포 가능한 상태로 준비해 두는 것까지 입니다. 실제 배포는 사람이 '승인' 버튼을 눌러 실행합니다.
• 지속적 배포 (Continuous Deploymeny): 사람이 개입하지 않고, 테스트를 통과한 코드를 실제 운영 서버에 바로 배포하는 단계입니다.

3. CD/CD를 사용하는 이유

개발이 끝나고 수동으로 서버에 접속해서 파일을 옮기고, 명령어를 입력해 배포했을때 이 방식은 실수가 잦고 시간이 오래 걸렸습니다. CI/CD를 도입하면 다음과 같은 변화가 생깁니다.

• 속도 향상 : 코드 수정부터 배포까지의 시간이 획기적으로 줄어듭니다.
• 안정성 : 자동화된 테스트가 미리 걸러주기 때문에 서비스가 죽는 일이 적어집니다.
• 피드백 루프 : 사용자의 피드백을 빠르게 반영하여 서비스를 개선할 수 있습니다.

요약하자면 : CI는 코드 합치고 테스트하기, CD는 합친 코드를 서버에 올리기를 자동화한 것이라고 이해하시면 됩니다.

---

GitLab CI/CD는 Git 플랫폼 안에 내장된 강력한 자동화 도구 입니다. 별도의 서버 설치 없이 .gitlab-ci.ymi 이라는 설정 파일 하나만으로 전체 과정을 관리할 수 있다는 점이 가장 큰 장점입니다.

1. GitLab CI/CD의 핵심 구조

GitLab CI/CD는 Pipeline(파이프라인) -> Stage(단계) -> Job(작업) 순서로 구성됩니다.

 

• Pipeline: 전체 자동화 프로세스의 실행 단위입니다.
• Stage: 작업을 논리적으로 구분한 단계입니다. (예: 빌드 단계, 테스트 단계 등)
• Job: 실제로 명령어를 실행하는 최소 단위입니다. 같은 Stage 안의 Job들은 병렬로 실행됩니다.

2. CI/CD 파이프라인 진행 순서도

일반적인 개발 흐름에 따른 순서는 다음과 같습니다.

[Step 1] Code Push (CI의 시작)

개발자가 코드를 수정하고 GitLab 저장소에 git push를 합니다. 이때 프로젝트 루트에 있는 .gitlab-ci.yml 파일을 GitLab이 감지하여 파이프라인을 가동합니다.

[Step 2] Build Stage

작성한 소스 코드를 실행 가능한 파일(Jar, Docker Image 등)로 컴파일하고 변환합니다.

• 핵심: 의존성 설치, 컴파일, 이미지 빌드

[Step 3] Test Stage

코드가 의도한 대로 작동하는지 검증합니다.

• 핵심: Unit Test(단위 테스트), Lint(코드 스타일 체크), 보안 취약점 스캔

[Step 4] Release/Deploy Stage (CD의 시작)

테스트를 통과한 결과물을 실제 서버나 클라우드 환경에 배포합니다.

• Staging: 운영 서버와 동일한 환경에서 최종 확인 (주로 자동)
• Production: 실제 사용자가 사용하는 서버에 반영 (자동 또는 수동 승인)

---

3. GitLab CI/CD의 동작 원리 (Runner)

GitLab CI/CD를 이해할 때 꼭 알아야 할 개념이 GitLab Runner입니다.

• GitLab Server: 파이프라인을 관리하고 명령을 내리는 두뇌 역할을 합니다.
• GitLab Runner: 실제로 명령어를 실행하는 일꾼입니다. (별도의 서버나 컨테이너에서 돌아갑니다.)

흐름: 코드 푸시 → GitLab 서버가 Runner에게 작업 지시 → Runner가 빌드/테스트 수행 → 결과를 서버에 보고

 

# 단계 정의 (순서대로 진행됨)
stages:
  - build
  - test
  - deploy

# 빌드 작업
build_job:
  stage: build
  script:
    - echo "컴파일 중..."

# 테스트 작업
test_job:
  stage: test
  script:
    - echo "유닛 테스트 실행 중..."

# 배포 작업
deploy_job:
  stage: deploy
  script:
    - echo "운영 서버로 배포 중..."
  only:
    - main # main 브랜치에 푸시될 때만 배포