개인 프로젝트에서는 main 브랜치 하나만 있어도 충분하지만, 수십 명의 개발자가 협업하고 수십만 명의 사용자가 접속하는 실무 서비스에서는 브랜치 구조가 곧 서버 인프라(배포 환경)의 구조가 됩니다. 이 문서는 무장애 배포를 위한 3단계 환경 격리 브랜칭 모델을 다룹니다.
1. 서버 환경과 브랜치의 1:1 매핑
| 브랜치 | 연결된 서버 인프라 | 역할 및 특성 | 배포 방식 |
|---|---|---|---|
| feature/* | 로컬 개발 환경 (Localhost) | 개발자 개인의 기능 구현 및 단위 테스트 | 로컬 실행 |
| develop | 사내 개발 서버 (Alpha / Dev) | 동료들의 기능들이 합쳐지는 첫 번째 통합 테스트 환경 | PR 머지 시 CI/CD 자동 배포 |
| staging (또는 release) | 스테이징 서버 (Beta / Stg) | 운영 DB 복제본과 동일한 스펙에서 QA팀의 최종 리허설 검증 | 릴리즈 후보 승격 시 배포 |
| main | 상용 운영 서버 (Production) | 실제 고객이 결제하고 서비스를 이용하는 무결점 환경 | 태그 생성 또는 배포 승인 시 배포 |
2. 실무 배포 승격 파이프라인 (Promotion Flow)
[ 단계별 코드 승격 라이프사이클 ]
1. 개발자들: feature/* ──(PR 검증)──> develop 브랜치로 통합
│
2. 이번 주 배포 스펙 확정 (Code Freeze) │
▼
3. staging 브랜치로 merge ─────────> 스테이징 서버에서 최종 QA 진행 (버그 발견 시 픽스)
│
4. QA 완료 및 상용 배포 승인 │
▼
5. main 브랜치로 merge ──────────> 운영 서버 자동 배포 (Blue/Green, 카나리)
│
6. 배포 시점 박제 ▼
Git Tag (v2.1.0) 발행3. 브랜치 보호 규칙 (Branch Protection Rules)
운영 서버를 날려먹는 사고를 시스템적으로 방지하기 위해, 실무에서는 GitHub/GitLab 설정에서 develop과 main 브랜치에 반드시 보호 규칙을 겁니다.
- 직접 푸시(Direct Push) 절대 금지: 아무리 대표나 테크 리드라도 터미널에서
git push origin main을 칠 수 없도록 차단합니다. 오직 PR을 통해서만 머지 가능합니다. - 최소 1인 이상의 코드 리뷰 승인(Approval) 필수: 다른 팀원이 "Approve"를 누르지 않으면 머지 버튼이 비활성화됩니다.
- CI 테스트 파이프라인 통과 필수: 단위 테스트, 린트 검사, 정적 분석이 통과(Green)해야만 머지가 허용됩니다.
