인프라 / DevOps·

삼쩜삼·2023년

잦은 배포를 언제나 안정적이고 쉽게- SimGit flow 기반 Git 브랜치 전략 개선기1

삼쩜삼(자비스앤빌런즈) 프론트엔드 팀이 팀 규모와 서비스 수 확장에 따라 Git Flow의 한계를 극복하고 SimGit Flow를 도입한 과정을 공유한다. 4명→10명, 서비스 8개, 세금 시즌 하루 3회 배포라는 환경에서 브랜치 조율 비용을 줄이고 QA 환경을 유지하는 맞춤형 전략을 설계했다. TBD와 비교 검토 과정과 팀 특성에 맞춘 커스터마이징 방법까지 담겨 있다.

핵심 포인트

Git Flow는 팀 확장 시 브랜치 의존성 조율 비용이 급격히 증가
TBD는 코드 리뷰 1라운드지만 팀의 QA 환경 요구를 충족하기 어려움
SimGit Flow로 코드 리뷰를 2라운드→1라운드로 줄이면서 스테이징 환경 유지
develop과 stage 브랜치를 추가해 기획·디자인·QA 팀의 사전 검증 구조 확보
잦은 배포로 무의미해진 버전 번호 대신 내부 배포 ID로 묶음 추적
팀 규모와 배포 주기를 고려한 전략 선택 프레임워크로 참고 가치 높음

상세 정리

초기 Git Flow: feature → develop → release → main 구조
팀 4명 → 10명 확장, 8개 서비스 운영, 세금 시즌 하루 3회 배포
브랜치 의존성 확인 커뮤니케이션이 개발 속도 저해의 주요 원인으로 지목
TBD 비교 검토: 단순하지만 프로덕션 배포 전 비개발직군 검증 환경 구성이 어려움
SimGit Flow 채택: 코드 리뷰 2라운드 → 1라운드 단순화, 배포 속도 향상
팀 커스터마이징: develop + stage 브랜치 추가로 QA/디자인/기획 검증 단계 유지
함께 배포되는 feature 묶음에 내부 ID를 부여해 배포 추적성 확보
버전 넘버링 대신 배포 ID 체계로 잦은 배포 환경에 맞는 관리 도입

왜 읽나빠른 배포 주기와 다수 서비스를 유지하는 중간 규모 프론트엔드 팀이 Git 브랜치 전략을 실용적으로 개선한 사례.

삼쩜삼 블로그

원문은 여기서 이어서 읽을 수 있어요

읽음 (0)

·takedown 요청

이 글과 비슷한