[CS] CI/CD 파이프라인

CI/CD 파이프라인

1. CI/CD를 왜 하는가?

• 코드 변경의 위험을 줄이기 위해
  • 개발자마다 작업한 코드를 합치다 보면 충돌 발생 가능
  • 코드 통합 시점마다 자동으로 테스트하여 오류를 사전에 발견
• 배포 속도를 빠르게 하기 위해
  • 수동 배포는 시간과 리소스 낭비, 실수 위험이 큼
  • 자동화된 빌드 및 배포를 통해 신속한 기능 릴리스 가능
• 서비스 품질을 유지하기 위해
  • 자동화된 테스트를 통해 코드 품질과 안정성 확보
  • 변경 사항이 실제 환경에 미치는 영향을 조기에 검증
• 개발-운영 간 협업 효율성 향상
  • 코드 커밋만으로 자동 빌드/테스트/배포 가능
  • 운영자는 배포 도구만 관리하고, 개발자는 기능에 집중 가능

---

2. 핵심 개념 정리

지속적 통합 (CI: Continuous Integration)

• 여러 개발자가 자주 변경한 코드를 공통 저장소에 지속적으로 통합
• 통합 시, 자동 빌드 및 테스트 실행
• 버그를 빠르게 발견하고, 코드 충돌을 최소화하는 것이 목적

지속적 전달 (CD: Continuous Delivery)

• 빌드된 코드를 언제든지 배포할 수 있는 상태로 유지
• 실제 배포는 사람의 승인 또는 수동 실행 필요

지속적 배포 (CD: Continuous Deployment)

• 테스트에 통과한 코드를 자동으로 운영 서버에 배포
• 사람의 개입 없이 바로 라이브 서비스로 적용됨

---

3. 실무에서 어떻게 구성하는가? (Docker + Jenkins 기반)

사용 기술

• Docker: 앱을 컨테이너로 감싸 어떤 환경에서도 동일하게 실행
• Jenkins: 파이프라인 자동화 도구, Git 이벤트 기반으로 빌드·테스트·배포 실행

 

4. CI/CD 파이프라인 구성 단계

1) 코드 변경 사항 푸시

• GitHub 등의 저장소에 코드를 커밋 & 푸시
• Jenkins가 Webhook 또는 SCM Polling으로 변경 사항 감지

2) Jenkins: CI 단계 자동 실행

• Git 코드 클론
• 의존성 설치 및 테스트 실행 (gradle build, npm install 등)
• 테스트 결과에 따라 다음 단계 진행 여부 판단

3) Docker: 앱 빌드 및 이미지 생성

• 테스트 통과 시, Dockerfile 기반으로 애플리케이션 이미지 생성
• 버전 태그 지정 후 이미지 저장소에 푸시
  • 예: Docker Hub, AWS ECR, Nexus

4) 컨테이너 배포 (CD 단계)

• 기존 컨테이너 종료 후, 새로운 버전 컨테이너 실행
• docker-compose 또는 쉘 스크립트로 프로세스 자동화
• 상태 확인 후 무중단 배포 가능

 

5. 실무 적용 시 고려사항

• 보안 관리
  • Docker Hub / AWS 인증 정보는 Jenkins Credential 기능 사용
  • Jenkins 접근 제한 및 GitHub Personal Token 관리 필요
• 무중단 배포 전략
  • docker-compose.override.yml 활용
  • 블루그린(Blue-Green), 롤링 배포(Rolling Update) 적용 가능
• 배포 환경별 설정 분리
  • .env.dev, .env.prod로 환경 변수 관리
  • docker-compose -f docker-compose.yml -f docker-compose.prod.yml 방식 적용
    • docker-compose.yml:
      기본 설정 (공통 환경: 이미지, 컨테이너 이름, 포트 등)
    • docker-compose.prod.yml:
      운영 환경만의 설정 (예: 환경 변수, 볼륨 경로, 로깅, 네트워크 등)
    • 최종 결과:
      두 개를 병합해서 사용하되, prod.yml의 설정이 같은 항목에서는 기본 설정을 덮어씌움
• 모니터링 및 오류 감지
  • Prometheus, Grafana, ELK Stack 등을 통한 배포 후 모니터링
  • Jenkins Slack/Webhook 연동으로 알림 구성