git flow를 버리고 gitlab flow를 선택한 까닭

Git Flow 방식이 불편했다

새로운 서비스 개발을 맡게 되면서 기존에 우리팀이 관습적으로 따르던 브랜치 전략을 재고해볼 기회가 있었다. 기존 방식은 당시에 가장 유명하고 널리 쓰인 Git Flow를 큰 변형 없이 그대로 가져다 쓰는 형태였다. (배민 개발팀의 Git-flow) 대중적인 전략이기에 나처럼 새로 들어온 팀원도 금세 적응할 수 있다는 장점은 있었다. 하지만 우리팀의 실질적인 개발 환경과는 맞지 않았다. 실질적 개발 환경에 적합한 브랜치 전략이라기보다는 널리 통용된 기반 지식을 일단 우리 상황에 끼워 맞춘 형국에 가까웠다.

release 브랜치와 stage 서버의 생애주기를 맞추는 방식에 문제가 있었다. git flow는 dev, main이라는 영구 브랜치를 운용하고 상황에 따라 release 브랜치가 생겨났다가 사라지는 구조다. dev/stage/prod 세 개의 개발 서버 중 두 개의 영구 브랜치를 각각 dev, prod 환경으로 매칭시키는 게 가능했지만 나머지 하나는 한시적으로만 매칭이 가능했다. 즉, 릴리즈 버전이 올라서 브랜치를 새로 만들 때 마다 개발자가 stage 서버에 일일이 매칭해줘야하는 절차가 필요했다. 당시 배포 환경인 AWS Amplify에는 이런 불편함을 해결해 줄 기능이 존재하지 않았다. 어떤식으로든 변화가 필요한 시점이었다.

고민했던 선택지

1. tag based 전략

같은 서비스를 개발하고 있는 백엔드 팀은 별 다른 문제가 없는지 궁금했다. 이 궁금증을 해결하는 과정에서 많은 힌트를 얻을 수 있었다.

먼저 브랜치 전략을 branch-based, tag-based 두 종류로 구분할 수 있다는 사실을 깨달았다. AWS Amplify나 vercel은 특정 브랜치와 환경을 매핑해서 해당 브랜치가 push되면 매칭된 환경으로 배포까지 이어지는 branch-based 방식으로 운용된다. 반면 우리팀 백엔드가 활용하는 방식은 tag-based였다. Jenkins 내에 스크립트를 짜서 tag와 관련된 특정 상황에 배포를 트리거하는 파이프라인이 존재했다. git flow도 따지고 보면 branch-based보단 tag-based에 가까워서 백엔드 팀은 별다른 문제가 없었던 것이다.

일반화해서 설명하자면, 항상 최신 버전의 코드만 제공해주면 되는 웹 브라우저의 특성상 branch-based 방식이 널리 쓰인다. 반면 하위 호환성을 따져야 하는 백엔드에서나 여러 버전이 공존할 수 있는 모바일 클라이언트에서는 tag-based 방식이 선호될 수 있다.

2. git flow 방식에 stage 영구 브랜치 추가하는 전략

이 방식은 tag-based와 branch-based 방식을 섞은 하이브리드 전략이다. 장점을 섞긴했으나 희석된 측면이 강하다고 판단했다. 앞석 말했듯 git flow의 장점은 누가 와도 쉽게 적응할 수 있게 규격화되어있다는 점인데, 그 틀을 깨야 한다는 점에서 메리트가 없다고 판단했다.

branch-based 방식의 gitlab flow로 변경하다

gitlab flow는 우리 개발환경에 딱 맞는 선택지였다. 정형화된 가이드 문서 가 있어서 바퀴 발명에 공들일 필요도 없고 그냥 가져와서 적용하면 될 정도였다.몇 가지 원칙만 지키면 단순했다.

1. master/pre-production/production 세 개의 영구브랜치와 feature 한 개의 임시 브랜치로 운용한다
2. feature 브랜치에서 테스트를 끝마치고 master에 머지하라
3. 가능한 단방향으로 (master -> pre-production -> production) 운용하라

크게 보기

git aliases 스크립트를 만들어서 네 가지 명령어로 관리했다.

1. git lab-start-feature
2. git lab-finish-feature
3. git lab-start-staging
4. git lab-finish-staging

마무리

비슷한 문제를 겪고있던 동료에게 위 방식을 권해보았더니 만족하며 썼던 기억이 있다. 그렇게 팀 내 규율로 자리잡아 여러 프로젝트에서 쓰이게 되었다. 위 스크립트를 활용하다가 팀 내 모바일 클라이언트와 모노레포 운용 경험이 쌓이면서 이번엔 아까 그 동료가 release-it + changeset 조합을 들고와서 한층 더 편리한 방식을 습득했었다. 이에 관한 정리는 다른 글에서 이어가보도록 하겠다.