deploy 브랜치 전략 활용 방법

Photo by Yancy Min on Unsplash

Background

당근마켓에서는 GitHub을 이용해서 소스코드를 관리하고 있습니다. 최근까지는 적은 인원이 빠른 개발을 하는 것을 목적으로 했기 때문에 특별한 브랜치 전략 없이 작업 후 테스트한 코드를 develop 브랜치에 merge 하고 서비스 배포 시 master 브랜치에 develop 브랜치를 merge 해서 배포하는 방식을 사용하고 있었습니다. 하지만 서비스가 성장함에 따라 다양한 기능 개발이 동시에 진행되면서 이전보다는 많은 개발자가 동시에 협업을 하고 있습니다. 그래서 이런 환경에서 발생했던 Git 브랜치 전략 관련 문제와 해결 방법에 대해서 이야기해보려고 합니다.

Git 브랜치 전략

협업의 규모가 커지면 개인의 스타일대로 git을 사용하는 것이 아니라 서로 규칙을 정해서 사용하게 되는데 이를 Git 브랜치 전략이라고 부릅니다. 최근에 많이 사용되고 있는 것으로는 Gitflow, GitHub flow, Gitlab flow 등이 있는데 프로젝트가 어떻게 운영되고 있느냐에 따라 각각 장단점이 있습니다.

당근마켓에서는 아직 전사적으로 어떤 Git 브랜치 전략을 선택할지 결정한 것은 없으나 최근에는 서버 레포지토리의 경우 Gitflow를 지향하는 방식으로 바꿔가고 있습니다. 우선은 지금까지 빠르고 편하게 사용했던 개발 협업 패턴을 크게 바꾸지 않으면서도 최소한의 규칙을 적용하고 있습니다.

Gitflow에서 기본적인 내용만 요약하면 사용하는 브랜치는 master, develop, feature, release, hotfix 브랜치이며 각각의 역할은 아래와 같습니다.

• master: Stable 한 코드의 Archive이며 master 브랜치로 배포하면 언제든지 stable 한 상태의 코드가 배포됨.
• develop: Deploy-ready 상태의 코드가 있는 브랜치로 release 브랜치와 새로운 feature 브랜치 생성의 base가 되는 브랜치임. develop 브랜치에 들어왔다는 것은 테스트가 완료되고 언제든 배포해도 된다는 의미임.
• feature: 작업 브랜치로 develop 브랜치를 기준으로 생성함.
• release: 배포가 나갈 때 생성하는 브랜치로 develop 브랜치를 기준으로 생성하며 배포 & 모니터링이 끝난 이후에 develop 브랜치와 master 브랜치로 merge함.
• hotfix: master 브랜치에 release 브랜치가 merge된 이후에 예상치 못한 버그나 문제가 발생했을 때 빠르게 수정하기 위한 브랜치임. master 브랜치를 기준으로 생성해서 고쳐야 할 기능만 고쳐서 배포한 후에 문제가 마무리되면 develop 브랜치와 master브랜치로 merge 함.

여기서 당근마켓에서는 우선 release, hotfix 브랜치는 사용하지 않고 master 브랜치를 배포 브랜치로 사용하고 있는 상황이지만 조만간 git 브랜치 전략을 정해볼 예정입니다.

gitflow, 완벽하지만은 않다

일반적으로 gitflow를 사용할 때 협업에는 큰 문제가 없다고 생각할 수 있지만 실제로 테스트 서버와 프로덕션 서버를 운영하는 환경에서는 한 가지 문제가 생깁니다. 물론 인프라 서버 자원이 풍부해서 feature 브랜치 별로 테스트 서버를 별도로 띄울 수 있다면 큰 문제가 없습니다. 하지만 그렇지 않은 경우 프로덕션 서버는 release 브랜치를 이용해서 배포 가능하지만 테스트 서버의 경우 각자의 feature 브랜치를 테스트하려면 다른 사람의 테스트를 기다려야 하는 문제가 발생합니다.

예를 들어 중고거래와 관련된 기능과 동네생활과 관련된 기능이 동시에 개발되고 있는 상황에서 서버 개발자의 로컬 테스트만으로는 충분하지 않은 경우 (대게 클라이언트 개발자와 협업을 하는 경우) 다른 구성원들도 함께 테스트를 하려면 내부 테스트 서버로의 배포가 필요합니다. 이때 개발 중인 기능은 테스트가 충분히 끝나지 않았기 때문에 develop 브랜치로 merge 할 수 없습니다. 따라서 feature 브랜치 상태에서 테스트 서버에 배포를 해야 하는데 이런 상황에 대한 해결 방안은 gitflow에서는 찾아볼 수 없습니다. 중고거래 관련 기능 feature 브랜치를 먼저 배포해서 테스트하고 그 후에 동네생활 관련 기능 feature 브랜치를 배포해서 테스트해야 하죠.

deploy 브랜치 전략

위 문제를 해결하기 위해 당근마켓에서는 deploy 브랜치 전략을 사용해보고 있습니다. 이 전략은 누가 어디서 정의한 것은 아니고 제가 이전 직장에서 경험한 케이스를 현재에 맞게 재구성해본 것입니다. 이 전략의 기본은 gitflow와 같지만 추가적으로 테스트 서버 배포를 위한 전용 브랜치를 이용하는 것으로 deploy/{month}라는 브랜치를 이용합니다. month의 경우 한 달의 기간을 의미하는 월을 의미하는데 이는 브랜치 수명을 너무 길게 가져가지 않기 위해 정한 것으로 꼭 이렇게 해야 한다는 것은 아닙니다.

deploy 브랜치 전략의 전체적인 플로우는 아래와 같습니다.

• 각 기능은 feature 브랜치에서 개발하며 기준 브랜치는 develop 브랜치임.
• deploy 브랜치 마스터(deploy 브랜치의 잘못된 사용을 막아주는 모더레이터 역할)가 브랜치 라이프 사이클에 맞춰 develop 브랜치 기준으로 deploy 브랜치를 생성함. (ex. deploy/02)
• deploy 브랜치는 테스트 서버에 배포되는 브랜치이며 CI를 운영하는 것을 권장함.
• 테스트 서버에서 테스트가 필요한 feature 브랜치를 각자가 deploy 브랜치에 merge commit과 함께 merge 함.
• deploy 브랜치에서의 기능 테스트가 끝나면 각 feature 브랜치는 Pull-request를 통해 deveop 브랜치로 merge됨.
• develop 브랜치에 commit이 추가되면 deploy 브랜치는 이 commit을 항상 merge 하여 최신 develop 브랜치 코드를 따라가야 함.

이 전략을 사용하게 되면 테스트 서버에서 각 feature 브랜치를 한 브랜치에 묶어서 배포를 할 수 있습니다. 같은 코드를 동시에 서로 다른 사람이 수정하는 것이 아니라면 Conflict이 생길 일 없이 테스트 서버에 배포하고 각 feature 브랜치에서 추가 개발을 하며 협업할 수 있습니다.

회고 및 정리

실제로 당근마켓에서 이 브랜치 전략을 2~3주간 사용해보면서 경험한 장점과 단점은 다음과 같습니다.

장점

• 모두가 기다리지 않고 테스트 서버에 배포를 할 수 있음.

단점

• deploy 브랜치와 develop 브랜치에 merge 하는 조건 등을 처음 접하는 사람은 헷갈려 하는 경우가 있음.
• deploy 브랜치는 테스트 서버 전용 브랜치이기 때문에 누군가의 실수로 테스트 서버에 장애가 날 수 있음. > 유닛 테스트 등이 잘 되어 있다면 피할 수 있음.
• 초반에는 deploy 브랜치 마스터의 역할을 하는 사람이 필요함.

도입 초기에 익숙하지 않은 구성원이 만들어낼 수 있는 실수가 있을 수 있지만 장점이 매우 큰 효율성을 가져오기 때문에 내부적인 개발 인프라 환경을 바꾸지 않고 git 브랜치 전략만으로도 큰 생산성을 확보할 수 있었습니다.