들어가며
명색이 ‘NEXT’란 명칭이 들어간 프로젝트 중에 행여나 하는 마음으로 찾아본 git branching 전략 트랜드… 아니나 다를까 git branching 모델 역시 NEXT가 있었네. 이름하야 TBD(Trunk Based Development; To Be Determined가 아니고…). 근간의 CI/CD는 DevOps를 넘어서 GitOps를 추구하고. git 관리의 핵심 중 하나가 branching 전략인데 이걸 그냥 넘어갈 수는 없서리.
TBD(Trunk Based Development) 이전에는
gitflow의 핵심을 요약하자면 다음과 같다.
•
master / develop 두 개의 무한 수명 branch. develop은 daily build가 수행되는 branch이며, develop에서 안정점을 찾으면 배포와 함께 안정적 버전을 뜻하는 master로 merge된다.
•
상기 과정을 위해 상당히 오랜 시간 유지되는 feature를 비롯해, release, hotfix 등의 조력 branch가 상시 동원된다.
TBD 등장
‘등장’… 이렇게 이야기하면 마치 근간에 나온 물건으로 보이겠지만, 개념 자체는 소프트웨어 개발 초창기부터 있었고, TBD란 말은 2010년대 초에 Paul Hammant란 소프트웨어 컨설턴트에 의해 유명해졌다고(chatGPT 왈). TBD로 꽤 유명해보이는 사이트 주인장이다(무려 구글 클라우드 센터에서 이를 참조하라 가이드 중. 그의 github도 참조. 얼굴 볼 수 있음)
다음은 위 사이트에서 발쵀한 TBD 그림이다(Scaled Trunk-Based Development).
간단히 핵심만 간추리자면 다음과 같다.
•
무한 수명 branch는 trunk (또는 master 또는 main ) 말곤 없다(release 는 배포 직전에만… 단명(short live)한다.
•
develop 등의 안정화를 중간 branch를 두지 않으며, release를 제외한 여타 branch는 ‘바로바로’ trunk로 merge된다.
이제 왜 새로운 개념이 아니라는지 바로 이해된다. 이건 그냥, gitflow등의 본격적 branching 모델을 채용하기 전에 일반적으로 쓰이는, ad-hoc한 느낌으로 사용하는 git 사용 모델과 별반 차이가 없다.
하지만 TBD가 강조하는 practice의 특징을 보면 gitflow와 차이가 명확히 드러나며 비교우위점 또한 마찬가지이다.
TBD의 Practice. 그리고 이를 위한 요구사항
•
develop branch 등의 예비 branch 없이 trunk에 직접 merge
◦
예비 branch를 두지 않는 만큼이나 merge되는 code의 quality가 보장되어야 한다.
◦
이를 위해 모든 테스트를 통과했을 때만 merge 가능하도록 포괄적 자동화된 테스트가 수행되어야 한다.
•
자주, 빠르게 trunk 에 source code merge
◦
장수(long live)하는 branch가 없어야 한다.
◦
그만큼 code review/merge가 빠르게 이루어져야 한다.
◦
review/merge가 빠르게 일어날 수 있도록 코드가 짧아야 한다.
•
소규모 코드 배포를 자주 수행
◦
CI/CD 자동화 프로세스가 잘 갖춰져야 한다.
◦
CI/CD 수행 시간이 짧아야 한다.
•
trunk 및 빌드 프로세스의 실행 가능 상태로 유지는 개발자의 책임
◦
이슈가 발생하면 개발자는 최우선으로 문제를 즉시 수정 또는 변경사항을 되돌려야 한다.
핵심은 gitflow에 있던 코드 안정성 보장을 위한 별도의 프로세스(e.g. develop branch)가 없다는 데 있다. 또한 장수하는 branch가 없다. 대신 이를 위한 요구사항이 늘었다(공짜 점심은 없다… 세상에 공짜는 없다). 그러면 이로써 얻는 것이 무엇일까?
TBD를 도입하면 무엇을 얻는가
•
위험을 야기하는 대규모 merge 제거
◦
git이 나오면서 대규모 merge가 없어졌다 싶었지만 예비 프로세스로 인해 다시 등장했다. 위험하다. 불안합니다. 바로 이걸 제거한다.
•
코드 안정화 단계 제거
◦
위험하고 불안하니 이를 제거할 단계가 필요하다. 위험하고 불안하면 터지기 마련이다. 터지면 뒷수습해야 한다. 바로 이걸 제거한다.
•
다중 branch 병합으로 인한 복잡성 감소, trunk의 최신상태 유지
◦
전 gitflow 그 오랜 시간 동안 보아왔는데 아직도 바로 이해가 안된다. 어려우니 전담 담당자(전담 포수?)가 필요하다. 바로 이걸 제거한다.
◦
merge가 자주 일어나므로 최신 trunk는 최신 상태를 반영한다.
•
결과적으로 code는 더욱 robust해짐
그리고 우리는 불안감해서 해방된다. 더 많은 자유를 얻는다. 밀린 작업으로부터. 주말, 야간 장애로부터.
TBD를 하기 위해서는? 요구사항 다시한번.
위에서 각 항목별 요구사항을 간단히 논했던 사항 정리이다.
•
소규모 작업/배치 - 단명의 feature branch
◦
작은 작업은 잦은 commit의 git의 철학과도 일맥상통한다. 특히, 기존 모델에서 보였던 특정 feature를 위한 오랜 branch/작업을 유지하는 것을 지양한다.
◦
아예 대놓고 매일 merge, 즉 커봐야 하루면 끝낼 수준으로 작업을 나누라네.
•
(무지 빠른) code review
◦
code review는 모든 작업의 최우선 과제라고 한다.
◦
code review가 늦어지면 악순환이 발생하고, 결국 TBD의 장점을 무력화한다네.
◦
늦어지면 reviewee는 PR을 꺼리게 되고, 그만큼 PR 단위는 커지고, review가 어려워져 이 때문에 또 늦어진다는 cycle이라고.
•
포괄적 자동화 테스트
◦
merge 전에 또는 극단적으로는 commit 전에 테스트를 이루어야 한다.
◦
이를 위해 테스트 자동화를 이루어야 - 이를 local은 물론 remote에서 조차 가능하도록 하는 도구가 있다고.
•
빠른 빌드/배포
◦
구글 클라우드 아키텍처 센터에서는 무려 ‘몇 분안에’를 논한다. 이렇게 안되면 해당 프로세스 개선의 기회라고…
◦
이러니 하루에도 몇번을 빌드/배포하라는 이야기가 나오는 듯 한다.
결론
•
•
또한, 서비스 운영을 하다보면 빌드/배포가 상당한 스트레스를 유발함을 알 수 있는데, 위와 같다면 ‘제거’까지는 아니더라도 상당부문 완화될 것임이 분명해 보인다.
•
무엇보다 TBD의 핵심은 사실 상 위험 분산, divide & conquer에 있으며, 이는 git이 추구하는 방향과 일치한다는 점에서 볼 때 믿을만 해보인다.
(여담이지만, '분산'은 일단 좋은 느낌이다. 독재 vs 민주(권력 분산), 메인프레임 vs 분산시스템, 국가통제통화시스템 vs 비트코인(분산 통화시스템)... 어, 그럼 비트코인이 짱? ㅎㅎ)
