핵심 요약
핏펫의 개발 스쿼드는 초기 GitHub Flow로 시작해 Git Flow 도입과 브랜치 간소화를 거쳐 수시 배포 체계로 전환한 경험을 공유합니다.
주요 경험
- 초기에는 main에 바로 병합하고 알파/스테이징은 필요 시 수시 배포하는 속도 우선의 흐름을 사용했습니다.
- 서비스 확대와 테스트 구조 필요성에 따라 develop, alpha, release, staging, main, prod 등 다층 브랜치 모델을 도입했습니다.
- 단점을 보완하기 위해 develop 브랜치를 제거하고 main에서 feature 브랜치를 생성한 뒤 alpha에 PR 및 병합하는 방식으로 수정했습니다.
- 배포 주기를 짧게 가져가려는 방향으로 일 2회 배포를 시도하고, 금요일 오후 배포는 주말 대응을 고려해 보류하는 정책을 적용했습니다.
- 브랜치를 간소화하고 기능 단위로 PR을 관리하는 흐름을 확립했으며, 자동화 차원에서 alpha 중심 PR 생성과 이후 프로세스 자동화를 도입하려는 계획을 세웠습니다.
얻은 인사이트
- 브랜치 전략은 팀 규모와 배포 주기에 맞춰 설계해야 하며, 자동화 없이는 수시 배포의 품질 관리가 어려워집니다.
- PR 관리와 자동화가 배포 속도와 안정성에 큰 영향을 주므로, 특정 환경에 우선 순위를 두고 자동화 포인트를 분리하는 것이 효율적입니다.
- 한 가지 최적의 전략은 없으며, 인원 변화에 따라 점진적으로 개선하고 자동화를 확장하는 태도가 중요합니다.
