Git-flow vs TBD 어떤 버전관리 전략이 유리할까?
팀의 규모가 커질수록 명확한 버전 관리 전략 수립은 중요해집니다.
저희 팀 역시 규모가 커지면서 명확한 버전 관리 전략을 수립할 때가 도래했었습니다.
유명한 버전 관리 전략인 Git-flow, Trunk based develop(TBD) 방식을 후보에 두고 알아봤었습니다. 그 때의 경험으로 두 버전 관리 전략의 특징을 알아보고 어떤 전략을 선택했는지까지 공유하는 자리를 갖고자 합니다.
Git-Flow
Git-flow의 특징은 각 브랜치마다 독립된 역할을 부여하는 것이 특징입니다.
두 개의 메인 브랜치와 나머지 서브 브랜치로 구성됩니다.
master branch: 운영 환경 배포
develop branch: 새로 구현된 기능들을 반영
release branches: 배포 준비단계 (QA, 버그픽스)
핫픽스 프로세스
배포 브랜치인 master에서 분기해서 변경사항 반영 후, develop, master 양쪽에 병합을 진행합니다.
이를 통해 develop와 master를 독립적으로 유지함으로써 현재 개발사항들과 핫픽스로 나가야할 수정사항을 분리하여 관리할 수 있습니다
릴리즈 프로세스
배포 대상 기능들이 develop에 병합되면 release로 분기하고 배포 준비 단계를 진행합니다.
release의 커밋들은 QA등의 검증 과정에서의 버그 수정사항들만 포함합니다.
Git flow의 장단점?
git flow의 주요 장단점이 무엇일까요?
가장 큰 장점은 엄격하게 구분된 브랜치 전략을 통해 안정성을 갖는다는 점입니다.
master 브랜치를 통해 릴리즈 버전 사이의 변경사항을 추적하기 쉬우며 핫픽스가 필요한 순간에도 master 브랜치 위의 커밋을 기준으로 원하는 수정사항만 반영해서 나가기 쉽습니다.
단점은 반대로 관리에 대한 오버헤드가 발생하는 점입니다.
배포 단계에서 여러 브랜치 분기 단계를 걸침으로 인해 오버헤드 발생하며, 팀 규모가 커질수록 합쳐지는 브랜치들로 인해 merge conflicts 처리가 복잡해집니다. 또한 작업이 끝난 feature 브랜치가 당장 릴리즈될 대상이 아닌 경우 병합 지연 관리에 대한 허들이 발생합니다.
Trunk based development (TBD)
TBD의 주요 특징은 두가지로 나뉠 수 있습니다.
- feature branch 없이 또는 짧은 생명 주기의 freature branch들로 구성하여 팀원들이 최신의 코드 상태를 공유하도록 유도합니다.
- CI를 활용하여 모든 master branch 커밋들이 릴리즈가 가능한 상태를 유지합니다.
그외 다른 중요한 특징으로, branch by abstration / feature flag를 이용하는 점입니다.
‘대체될’ 구성요소와 ‘대체할’ 구성요소가 배포될 코드에 공존하는 방식을 통해 Git-flow에서 발생하는 허들인 병합 지연에 대한 관리 허들을 줄입니다.
branch by abstration / feature flag
간단하게 정리하면 다음과 같습니다.
branch by abstration : 교체하려는 컴포넌트를 직접 접근하는 다른 컴포넌트들이 추상화를 접근하도록 수정하고, 추상화의 두번째 구현을 생성해서 교체하는 방법입니다.
예를 들어, 안드로이드에서 로컬 데이터 소스를 sharedPreference -> room db로 교체한다고 할 때 로컬 데이터 소스를 추상화하여 기존의sharedPreference 참조 구현체와 작업 중인 room db 참조 구현체를 공존하게하는 방법입니다.
작업이 완료되면 room db 참조 구현체를 참조하도록 수정합니다.
feature flag : 빌드타임 또는 런타임에 적용할 수 있는 플래그로 on/off를 통해 기능 단위의 교체를 이룹니다.
이는 외부의 서비스를 의존하는 경우(서버의 업데이트를 기다려야한다거나)에 특히 유효합니다.
릴리즈 프로세스
릴리즈 주기가 굉장히 빠른 팀의 경우 별도의 release브랜치를 생성하지 않고 trunk 위에서 바로 릴리즈를 진행합니다. 하루에 한 건 이하의 릴리즈를 수행하는 팀의 경우 release브랜치를 생성하고 버그 수정 커밋들을 포함한 후 릴리즈를 진행할 수 있습니다.
다만 코드 수정은 항상 master에서 진행하며, qa 단계에서 검출한 버그, 핫픽스 또한 master에서 수정하고 cherry pick을 통해 릴리즈 브랜치에 반영합니다.
TBD의 장단점?
그럼 TBD의 주요 장단점은 무엇일까요?
일단 무엇보다 큰 장점은 CI/CD를 효과적으로 이용하여 git-flow 에서 발생했던 관리 오버헤드들을 줄인다는 점입니다. 다만 반대되는 단점으로 CI/CD 구성이 잘 되어있어야하며, 배포가 사용자에게 공개되기까지의 시간이 오래걸릴수록 효과적으로 활용하기 어려운 점을 꼽을 수 있습니다.
그래서 어떤 전략을 선택했나요?
결국 저희 팀은 git-flow 방식을 채택했습니다.
TBD 또한 매우 매력적으로 여기긴 했으나, 안드로이드의 배포는 소스코드 배포로 종료되는 것이 아닌 각 마켓의 심사 과정이 남아있다는 점이 TBD를 활용하기엔 큰 허들이었습니다.
TBD는 빠른 배포 프로세스를 이용하여 미쳐 잡아내지 못한 문제점을 빠르게 수정 후 재배포를 통해 이점을 얻어내는 것이 큰 특징입니다.
마켓이 중간에 참여하는 안드로이드에는 이 이점을 살리지 못한다고 판단하여 git-flow 방식을 채택하게 되었습니다.
아무리 완벽하게 개발을 해도 개발에 있어선 언제나 크고작은 버그는 발생한다 생각합니다. 그렇기 때문에 만약 배포단계에 마켓이나 다른 서비스를 의존하지 않는다면 TBD가 좀 더 매력적인 전략이 될 듯 합니다.
