dev 브랜치 기반의 CI/CD 파이프라인 설계

목표는 dev 브랜치에 코드가 푸시될 때, 테스트, 빌드, 스테이징 배포까지의 전 과정을 자동화하고 빌드 시간 단축

문제점: 반복적인 의존성 설치와 수동 빌드

기존 워크플로우는 두 가지 비효율적인 부분

* 느린 빌드 시간: Docker 이미지를 빌드할 때마다 매번 uv pip install을 통해 파이썬 의존성을 새로 설치했습니다. 이과정은 네트워크 상황에 따라 빌드 시간을 지연시키는 주된 원인

* 수동 프로세스: 테스트와 Docker 이미지 빌드, 배포가 별도의 워크플로우로 분리되어 있어 개발자가 각 단계를 수동으로 실행

해결책: `.venv` 캐싱과 통합 파이프라인 구축

이 문제들을 해결하기 위해 다음과 같은 두 가지 핵심 전략을 적용

첫째, `.venv` 캐시를 활용하여 빌드 시간을 단축

CI의 test 단계에서 생성된 파이썬 가상 환경(.venv)을 캐시하고, Docker 이미지를 빌드할 때 이 캐시를 그대로 재사용하는 아이디어입니다. 이를 위해 기존 Dockerfile을 수정하는 대신, 캐시 전용 Dockerfile.cached를 새로 생성

`Dockerfile.cached`

위 Dockerfile은 uv pip install 명령 없이, CI 환경에서 이미 모든 의존성이 설치된 .venv 디렉터리를 통째로 복사

이로써 Docker 빌드 단계에서는 의존성을 설치하는 시간이 전혀 소요되지 않음

둘째, `dev` 브랜치 기반의 통합 CI/CD 워크플로우를 구축

dev 브랜치에 코드가 푸시되면, 테스트 → 빌드 → 배포가 자동으로 이어지는 통합 워크플로우

 

(자동 파이프라인: dev → staging)

[dev/dev-test 브랜치 push]
       ↓
[test]  Redis 준비 → 의존성 설치 → pytest 실행
       ↓ (성공 시)
[build_rc] RC 태그 계산 → Docker 이미지 빌드 & Harbor 푸시
       ↓
[deploy_staging] 새 RC 이미지를 스테이징 환경에 배포

(수동 승격: Staging → Production)

[Release to Staging] (workflow_dispatch, rc_version_tag 입력)
   ↓
[Harbor 로그인] → [Staging 서버에 .env + compose 전송] → [docker compose up -d 실행]
   ↓
RC 버전이 Staging 환경에서 실행됨
   ↓ (검증 완료 후)
[Release to Production] (workflow_dispatch, version_tag 입력)
   ↓
[Harbor 최신 RC → 정식 태그 Re-tagging + Push]
   ↓
[Production 서버 배포: docker compose up -d --remove-orphans]
   ↓
[Release 태그 main 브랜치에 병합]
   ↓
최종 서비스 운영 반영 완료

 

cicd 파이프라인