blog

운영 장애 Hotfix 대응 브랜치 흐름

Front-end / Git#Git#hotfix#브랜치 전략#배포

운영 중인 서비스에 급한 수정이 필요할 때 사용한 브랜치 흐름이다. 브랜치는 세 단계로 운영했다.

브랜치역할
main운영(production) 배포 기준
sync운영 반영 전 검증용(스테이징) 배포 기준
dev다음 버전 개발 통합

흐름

  1. 운영 기준점에서 hotfix 브랜치 분기 현재 운영에 배포된 커밋(보통 main 또는 운영 배포 태그)에서 hotfix/*를 만든다. dev에는 아직 운영에 나가면 안 되는 기능이 섞여 있으므로 dev에서 분기하지 않는다.
  2. 수정 후 hotfix → sync 병합
  3. 태그를 붙이고 검증 환경에 배포
  4. 검증에 이상이 없으면 sync → main 병합
  5. 운영 배포
  6. main → dev 병합 hotfix 내용을 개발 브랜치에도 반영한다. 이 단계를 빠뜨리면 다음 정기 배포 때 수정 사항이 사라지거나, 같은 버그가 다시 나온다.
main ──●──────────────────●── (운영 배포)
       │                  ↑  ↓
       └─ hotfix/x ─● ─→ sync ─(검증)
                             ↓
dev  ─────────────────────────●── (main 병합으로 동기화)

주의할 점

  • 병합은 --no-ff로 해서 hotfix 흔적이 기록에 남도록 한다.
  • 6단계에서 dev와 충돌이 나면, 같은 부분을 dev에서 이미 다르게 고쳤는지 확인하고 해결한다.
  • 태그(예: v1.4.1)를 붙여 두면 어떤 수정이 어느 배포에 포함됐는지 추적하기 쉽다.