1. CI 워크플로우 (Pull Request)

트리거: PR 생성 또는 업데이트 (→ main, dev)

동작 과정:

1. 변경 감지
   • detect-changes.sh 스크립트 실행
   • PR의 target 브랜치(base)와 비교하여 변경된 파일 분석
     • feature → dev PR: dev 브랜치와 비교
     • dev → main PR: main 브랜치와 비교
   • 영향받는 서비스 목록 생성
2. 병렬 CI 실행
   • 변경된 서비스만 선택적으로 CI 작업 실행
   • 각 서비스별로 독립적인 Job 실행:
     • Lint 검사
     • 단위 테스트
     • Next.js 빌드 (Frontend만)
     • Docker 이미지 빌드 및 푸시
       • feature → dev: 빌드 테스트만 (푸시 안 함)
       • dev → main: 빌드 후 NCP Registry에 푸시 (Frontend만)
3. CI 결과 요약
   • 모든 CI 작업 결과 취합
   • 실패 시 PR 머지 차단

2. CD 워크플로우 (Main Branch)

트리거: main 브랜치로의 push (merge 완료)

동작 과정:

1. 변경 감지

   • 이전 커밋과 비교하여 변경된 서비스 감지

2. 배포 전략 (서비스별 차이)

   Frontend (NCP Container Registry 사용):

   • CI 단계(dev→main PR)에서 이미 이미지 빌드 및 푸시 완료
   • CD는 SSH로 프론트엔드 서버에 접속
   • 서버에서 CI가 푸시한 이미지를 Registry로부터 pull
   • 컨테이너 실행 (태그: {commit-sha})
   • 장점: 빌드 시간 단축 (소형 서버 부담 감소), CI에서 빌드 완료 후 배포만 수행

   Backend Services (서버 빌드 방식):

   • GitHub Actions Runner가 SSH로 배포 서버에 접속
   • 배포 서버에서 직접 git pull로 최신 코드 가져오기
   • 변경된 서비스만 docker-compose build 및 docker-compose up -d 실행
   • 이전 이미지 정리 (docker image prune)
   • 장점: 이미지 레지스트리 불필요, 설정이 간단

3. 배포 결과 요약

   • 모든 배포 작업 결과 취합
   • 실패 시 알림

mindmap
    root((CI/CD Pipeline))
        Frontend
            이유: 소형 서버 1시간 빌드
            CI 단계
                dev→main PR
                GitHub Actions 빌드
                NCP Registry 푸시
                빌드 캐시 저장
            CD 단계
                이미지 Pull
                컨테이너 실행
                검증된 아티팩트 배포
        Backend
            이유: 단순한 구조 선호
            CI 단계
                빌드 검증만
                Docker Build 테스트
            CD 단계
                git pull
                docker-compose build
                docker-compose up