[blog - 7] 블로그 v2 리뉴얼과 함께 정리한 배포 전략

이번에 블로그를 v2로 리뉴얼하면서, 프로젝트의 배포 전략을 처음부터 다시 설계했다.

특히 버전 관리 방식과 브랜치 역할을 명확하게 구분해두면 운영과 개발이 훨씬 깔끔해져서, 이번 기회에 구조를 확실히 정리해뒀다.

목표

• 서비스 버전 관리를 체계적으로 운영할 것
• 브랜치별 역할을 명확하게 구분해 협업 및 배포 혼란을 줄일 것

브랜치 구조와 역할

• feature/

  • develop에서 분기해서 기능 개발을 진행한다.
  • 작업이 끝나면 다시 develop으로 PR을 보낸다.

• develop

  • 통합(스테이징) 브랜치다.
  • 모든 기능은 이 브랜치에서 검증을 거친 뒤 main으로 병합한다.
  • PR 머지 전에는 반드시 CI를 통과해야 한다.

• main

  • 운영 기준 브랜치다.
  • 태그/릴리즈 생성의 기준이 된다.

전체 파이프라인 요약

1) PR 생성 시 (feature → develop 또는 develop → main)

• 트리거: pull_request (base=develop 또는 base=main)
• 실행 작업: Lint → Next.js Build
• 조건: 두 작업이 모두 통과해야 merge 가능
  • 브랜치 보호 규칙으로 머지 조건을 강제했다.

2) develop 브랜치에 push될 때

• 트리거: push (branch=develop)
• 실행 작업: Vercel 프리뷰 배포
• 결과: develop 상태의 프로젝트가 미리보기 환경으로 배포된다.

3) main 브랜치에 push될 때

• 트리거: push (branch=main)
• 실행 작업: 커밋 히스토리를 기반으로 태그 생성 → GitHub Release 생성
• 결과: 배포 버전이 태깅으로 남는다.

4) 릴리즈 기준 배포

• 트리거: GitHub Release가 published 된 시점
• 실행 작업: 릴리즈 정보를 기반으로 실제 프로덕션 배포
• 결과: 태깅된 버전이 운영 환경에 반영된다.

마치며

필요할 때마다 새로 붙이던 배포 흐름을 이번에 정리하면서, 빌드·배포·버전 관리가 한눈에 들어오도록 만들었다.

앞으로는 develop과 main의 역할이 명확해진 만큼, 기능 개발과 배포 과정도 안정적으로 관리할 수 있을 것 같다.