CI/CD 개념 이해하기

🚀 CI: Continuous Integration

깃허브를 몰랐던 시절,
팀 프로젝트를 하면 "내가 A 부분을 할게, 네가 B 부분을 해!" 하며
소스코드 파일을 주고받아 완성했던 적이 있다.

소규모 프로젝트라 충돌도 거의 없었고, 있어도 금방 고쳤지만
지금처럼 규모가 큰 프로젝트에서 그렇게 해야 한다면 눈앞이 캄캄하다.

• 이 코드 누가 작성했나요?
• 테스트했나요? 제 환경에서는 안 되는데요?

체계적인 코드 통합의 필요성을 실감하게 되는 순간이다.

CI는 Continuous Integration, 즉 지속적인 통합이라는 의미로
새로운 코드 변경 사항이 자동으로 빌드되고, 테스트되어 병합되는 과정을 말한다.

대표적인 CI 도구로 Jenkins, GitHub Actions 등이 있다.

자동화된 빌드 및 테스트

CI 서버 혹은 파이프라인은 Git 저장소에 변경 사항이 push되거나
PR이 올라올 때마다 자동으로 빌드하고 단위 테스트와 통합 테스트를 수행한다.

이때 빌드와 테스트 과정에서 오류가 발생하면 즉각 알림을 보내
개발자가 문제를 빠르게 파악할 수 있다.

🚀 CD: Continuous Delivery/Deployment

CI와 함께 같이 묶이는
CD는 Continuous Delivery/Deployment 두 가지 의미를 가진다.

🚀 Continuous Delivery

지속적 제공이라고 한다.

 

Continuous Delivery는 CI 단계에서 검증되어 배포가 준비된 코드를 레포지토리로 가져오는 것(제공, delivery)을 자동화한다.
배포 가능한 상태이지만, 실제로 배포를 진행할지는 담당자의 승인을 거친다.

🚀 Continuous Deployment

지속적 배포라고 한다.

 

Delivery와 달리

CI 단계에서 테스트가 모두 통과하면 자동으로 프로덕션 환경으로 배포되는 과정이 모두 자동화되어 있다.

 

즉, 담당자의 승인 없이도 코드가 커밋되고 테스트를 통과하면
자동으로 프로덕션 환경에 배포된다.

배포 파이프라인 예시

전형적인 CD 파이프라인 단계이다.

 

 

 

1. Checkout: Git 저장소에서 코드 가져오기

• 개발자가 깃허브에 push한 최신 코드를 CI/CD 서버가 받아온다.
• 예시로 GitHub Actions에서는 actions/checkout@v3 같은 액션을 사용한다고 한다.

2. Build & Test

• Java의 jar과 같이 실행 가능한 형태로 빌드한다.
• 단위 테스트와 통합 테스트 등을 거친다.

3. Docker Build & Push: Docker 이미지 생성 후 ECR 업로드

• Dockerfile을 이용해 Docker 이미지를 만들고 ECR에 업로드한다.

4. Deploy: ECS 서비스 업데이트

• 업로드 된 Docker 이미지는 이 이미지를 실제로 실행할 ECS로 전달된다.
• 이 단계에서 새 이미지를 기반으로 서비스가 업데이트된다.
  • 롤링 방식: 기존 인스턴스에서 조금씩 교체해나가는 방식
  • Blue/Green 방식: 기존 버전(Blue)과 새 버전(Green)을 동시에 띄우고, 트래픽을 전환하는 방식

6. Post-deploy checks: 배포 후 검증 단계

• 배포 후 실제 서비스가 정상 동작하는지 확인한다.
  • 헬스 체크, 모니터링, 알림, 로그 확인 등

이렇게 모든 과정이 자동화되어 있으면
개발자는 오직 코드를 깃에 push하기만 하면 된다!

 

사람이 굳이 작업할 필요 없이 안정적으로 배포되는 것이 CD의 목적이다.

참고자료

• JSCODE 박재성님 CI/CD 입문 실전 강의
• 코드잇 스프린트 강의
• CI/CD란 무엇인가 (Feat. DevOps 엔지니어)
• CI/CD(지속적 통합/지속적 배포)란?