서비스 배포 프로세스
본 문서는 서비스 레포의 배포 프로세스를 설명합니다.
브랜치 구조
| 브랜치 | 환경 | 용도 |
|---|---|---|
feat/* | Local | 기능 개발 (feat, fix, chore, design, refactor, test, docs...) |
test | Test 서버 | QA 진행 |
main | Stage 서버 | E2E 테스트 (PR 리뷰 완료된 코드) |
release | Production 서버 | 실서버 배포 |
워크플로우
┌─────────────────────────────────────────────────────────────────────────┐
│ Service Branching │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ feature/* test main release │
│ │ │ │ │ │
│ │ merge │ │ │ │
│ ├───────────────>│ │ │ │
│ │ │ │ │ │
│ │ [QA] │ │ │
│ │ │ │ │ │
│ │ │ PR │ │ │
│ ├────────────────┼──────────────>│ │ │
│ │ │ │ │ │
│ │ │ [E2E] │ │
│ │ │ │ │ │
│ │ │ │ PR │ │
│ │ │ ├─────────────────>│ │
│ │ │ │ │ │
│ │ │ │ [Deploy] │
│ │
│ ───────────────────────────────────────────────────────────────────> │
│ Local Test Stage Production │
│ │
└─────────────────────────────────────────────────────────────────────────┘상세 프로세스
1. Feature 브랜치 생성 및 개발
bash
# main에서 feature 브랜치 생성
git checkout main
git pull origin main
git checkout -b feat/my-feature브랜치 네이밍 컨벤션:
feat/- 새로운 기능fix/- 버그 수정chore/- 빌드, 설정 등 기타 작업design/- 디자인 관련 수정refactor/- 코드 리팩토링test/- 테스트 코드docs/- 문서 작성- ...
2. Test 브랜치에서 QA
개발 완료 후 test 브랜치에 머지하여 테스트 서버에 배포합니다. Vercel을 통해 자동 배포됩니다.
bash
git checkout test
git merge feat/my-feature
git push origin testa. 테스트 서버에서 QA 진행
3. Main 브랜치로 PR 생성
QA 완료 후 main 브랜치를 향해 Pull Request를 생성합니다.
bash
# GitHub에서 PR 생성
# base: main <- compare: feat/my-featurea. 코드 리뷰 요청
b. 리뷰어 피드백 반영
c. Approve 후 머지
4. E2E 테스트 (Stage)
main 브랜치에 머지되면 Stage 서버에 배포되고 E2E 테스트가 실행됩니다.
E2E 테스트 스케줄 (금요일 오후 제외)
- 오전 10:30
- 오후 15:30
5. Release 브랜치로 배포
E2E 테스트 성공 후 release 브랜치를 향해 PR을 생성합니다.
bash
# GitHub에서 PR 생성
# base: release <- compare: main- PR의 제목은
251223 오전 정기 배포혹은251223 오후 정기 배포와 같은 형태로 작성합니다. - 이 PR은 별도 리뷰 없이 머지 가능
- 머지 시 Production 서버에 자동 배포
환경별 요약
| 항목 | Feature | Test | Main | Release |
|---|---|---|---|---|
| 환경 | Local | Test 서버 | Stage 서버 | Production |
| 용도 | 개발 중 | QA | E2E 테스트 | 실서버 |
| 배포 | - | Vercel | Vercel | Vercel |