blog
운영 장애 Hotfix 대응 브랜치 흐름
Front-end / Git#Git#hotfix#브랜치 전략#배포
운영 중인 서비스에 급한 수정이 필요할 때 사용한 브랜치 흐름이다. 브랜치는 세 단계로 운영했다.
| 브랜치 | 역할 |
|---|---|
main | 운영(production) 배포 기준 |
sync | 운영 반영 전 검증용(스테이징) 배포 기준 |
dev | 다음 버전 개발 통합 |
흐름
- 운영 기준점에서 hotfix 브랜치 분기
현재 운영에 배포된 커밋(보통
main또는 운영 배포 태그)에서hotfix/*를 만든다.dev에는 아직 운영에 나가면 안 되는 기능이 섞여 있으므로dev에서 분기하지 않는다. - 수정 후
hotfix→sync병합 - 태그를 붙이고 검증 환경에 배포
- 검증에 이상이 없으면
sync→main병합 - 운영 배포
main→dev병합 hotfix 내용을 개발 브랜치에도 반영한다. 이 단계를 빠뜨리면 다음 정기 배포 때 수정 사항이 사라지거나, 같은 버그가 다시 나온다.
main ──●──────────────────●── (운영 배포)
│ ↑ ↓
└─ hotfix/x ─● ─→ sync ─(검증)
↓
dev ─────────────────────────●── (main 병합으로 동기화)
주의할 점
- 병합은
--no-ff로 해서 hotfix 흔적이 기록에 남도록 한다. - 6단계에서
dev와 충돌이 나면, 같은 부분을dev에서 이미 다르게 고쳤는지 확인하고 해결한다. - 태그(예:
v1.4.1)를 붙여 두면 어떤 수정이 어느 배포에 포함됐는지 추적하기 쉽다.