2022년 상반기에 회사 Git 브랜치 전략을 고민하고 개선했었고 그 내용을 정리해보고자 한다.
인트로
SVN에서 GIT으로 넘어온 지 2년이 지났고, 깃 명령어를 다루는 데 있어 많이 익숙해진 시점이었다. 하지만 개발자들이 늘어나고, 배포 주기도 짧아지고 엔터프라이즈 사업이 확대되면서 좀 더 전략적인 접근이 필요해졌다.
기준 삼을 전략을 찾아보던 중 Git Flow 전략과 Github Flow 전략을 만났다. Github Flow 전략을 활용하기엔 테스트 자동화 등이 잘 준비되어있지 않았다. 그래서 Git Flow 전략을 기준 삼고자 면밀하게 들여다보게 되었다. 이때, 우아한 형제들의 '우린 Git-flow를 사용하고 있어요'를 많이 참고했다.
Git Flow 는 무엇인가?
Git Flow 전략은 feature > develop (개발) > release > hotfix > master (운영)에 해당하는 기본 5가지 브랜치를 활용한다.
짧게 각 브랜치별 설명을 해보자면,
1. Feature 브랜치는 Develop(개발) 브랜치를 기준으로 생성하며, 기능, 과제 단위로 개발을 진행하는 브랜치이다.
2. Develop 브랜치는 개발의 기준이 되는 브랜치로 개발자들의 Feature 브랜치만 모이는 브랜치이다.
3. Release 브랜치는 Develop(개발) 브랜치를 기준으로 생성하며 QA 과정을 통해 운영 배포를 준비하는 브랜치이다.
4. Hotfix 브랜치는 Master(운영) 브랜치를 기준으로 생성하여 운영 긴급 이슈를 해결하고 운영 배포하는 브랜치이다.
5. Master 브랜치는 현 운영과 동일한 소스를 가지는 브랜치다.
Develop, Master 가 각각 개발, 운영의 주 브랜치가 되고, Feature, Release, Hotfix가 보조 브랜치로서 역할한다.
Git Flow 포인트 : 릴리즈 기간 때 핫픽스
한가지 포인트 지점이 있다고 하면, Hotfix 브랜치 작업이 끝나면 Master 브랜치에만 병합 후 배포 하는 것이 아니라 Develop 브랜치에도 병합을 해두어야 한다는 점이며 , 릴리즈 기간이면 Release 브랜치에 병합해야 한다. (위 사진 그래프에는 나오지 않은 플로우이다) 운영에 고쳐둔 소스가 곧 배포를 앞둔 릴리즈 소스에 병합이 안 되어 있다면 '핑퐁' 지옥에 빠질 수밖에 없기에 매우 중요한 포인트 지점인 것 같다.
위 그래프에서는 이 포인트 지점이 없어서 직접 그려봤다. 첫번째 핫픽스는 Develop 브랜치에 병합하지만, 두 번째는 Release 브랜치에 병합한다. (해야만 한다)
현재 브랜치 전략의 문제점
Git flow 전략을 보고 2년간의 경험에 빗대어 보았을때 우리 브랜치 전략에 가장 큰 문제는 Release, Hotfix, Master를 모두 master 브랜치에서 썼다는 점이다. (물론 이렇게 쓰고 CI & CD가 완벽했더라면 Github flow 전략으로 녹여 충분히 잘 썼을 것이다..) 릴리즈 기간 동안엔 운영과 동일한 소스의 브랜치가 존재하지 않았다. 릴리즈 기간에 핫픽스가 발생한다 치면 운영 서버의 소스를 직접 수정해야 하는 불상사가 발생했다.
또, hotfix를 처리함에 있어 무조건 master 브랜치에 병합을 하고 시작하니 이슈 처리를 잘 못한 경우 revert 혹은 커밋이 여러개 박히는 불상사도 발생했다.
이러한 불상사를 그래도 사람이 많지 않을때는 대수롭지 않게 여겼던 것 같다. 아래 사진을 보면 네모로 친 영역이 릴리즈 기간인데, 그 기간에 핫픽스를 치고 배포를 하고 이런 과정 자체가 말이 안 되는 부분이었다.
개선 후
Git-flow 브랜치 전략과 기존의 배포 플로우를 잘 융합해서 우리만의 브랜치 전략을 세웠다. 확실하게 Release, Hotfix, Master 브랜치가 구분되었기 때문에 배포의 안정성을 높일 수 있게 되었다. 되게 간단한 배포 전략 수립일 수도 있지만 내겐 기나긴 연구의 결과물이었다.
Git을 공부히고 팀원들에게 알게 된 내용을 공유하고
브랜치 전략에 대해 공부하고 팀원들에게 알게 된 내용을 공유하고
우리는 어떻게 하면 좋을 것 같다고 제시하고 설득하고
실제 전략에 맞춰 시행해보고 안정성이 높다는 걸 모두가 느끼는
모든 과정 자체가 매우 자잘하고 긴 시간이었다.
보통 이런 일은 기능 개발과 같은 일정이 정해진 업무가 아니다 보니까 시나브로 해내야만 했던 것 같다.
더 고민해봐야되는 지점
SaaS 서비스와 Enterpise 서비스 모두 원 소스로 이뤄지고 있지만 제 각기 다른 master 브랜치를 가지고 있기 때문에 그 master 들간의 병합을 시도할 때 굉장히 많은 리소스가 들어가고 있다. (develop은 하나인데, master는 여러 개) 만약 master1의 이슈가 발생하면 사실은 master2, master3, master4 모두 적용이 되어야 하는데 배포 시점도 다르기 때문에 함부로 병합할 수도 없다. 그러면 develop에라도 병합이 잘 되어야 하지만 그것이 잘 안 이루어지고 있어 굉장히 복잡해지고 있다. 어떻게든 해내고 있지만 이 부분도 연구를 통한 전략이 필요하다. 설득부터 실제로 시행되기까지의 과정을 시도해야 한다.
위 배포 전략을 안정화시키고 '더 고민해봐야되는 지점'에 대해 의견을 냈지만 2023년 상반기까지는 시행되지 못했다. 현실적으로 전략을 시행하기엔 제한사항이 많았기 때문인 것 같다.
진짜 뜬금없는 이야기 : develop은 하나인데, master는 여러 개
약간 뜬금 없을 수 있는데 육각기둥에 대한 이야기를 해보려고 한다.
develop은 하나인데, master는 여러 개라는 이야기를 듣고 이런 전략이 어떨까 얘기를 했다.
육각기둥이 있는 중앙에는 develop 축이 있고, 각 육각기둥의 꼭짓점의 축들은 master1, master2,... master6이 된다고 빗대보면 중앙 develop 축부터 각 꼭짓점 master 축까지는 위에서 설명한 Git-flow 전략을 각 축에서 시전 하면 된다. 그래서 이 전략은 git-prism-flow! (깃 각기둥 플로우 ㅋㅋㅋㅋㅋㅋ)
전공이 수학이었어 이런 생각을...한 것 같기도 하다.
