TBD: Trunk Based Development
2023.02.25
기존에는 git브랜치 전략으로 git-flow를 기반의 git 브랜치 전력으로 개발을 진행했다. 보편적으로 사용하는 방식이기에 협업을 할때 모두의 이해도가 높아서 사용하기 편리했다.
단점으로는 프로젝트를 진행하다보면 브랜치가 너무 많아지게 되며 브랜치를 관리하는데 어려움이 생겼다.
우리는 main, stage, dev와 각 feature 브랜치와 hotfix 브랜치를 만들어서 개발을 진행했었다. 하지만 팀 규모에 비해서 업데이트가 매우 잦은 프로젝트였고, Monorepo로 관리되는 프로젝트였기 떄문에 한명의 개발자가 관리하는 브랜치 수가 많아서 버전 업데이트를 할때 각 브랜치를 병합시킬때 혼동이 생기는 문제가 있었다.
이미 개발한 브랜치를 main까지 올렸다가 제거했다가 나중에 다시 추가하는 경우도 있었고, 그 과정에서 병합 출동이 빈번했다.
예를 들자면 A라는 feature 브랜치가 main에 올라가 있는데, B라는 기능을 main에 올리면서 잠시 A기능을 main에 제거 했다가, C라는 기능을 추가하고 다시 A기능을 추가하는 경우가 있다. 해당 코드는 한 페이지안에 들어 있는 기능이 였기에, 브랜치로만으로 단순히 merge하고 rebase하기에는 여러 충돌을 만들었다.
이러한 문제들을 격고 나서 TBD를 도입하기로 했다.
TBD는 Trunk Based Development의 약자로, git-flow와는 다르게 main 브랜치를 중심으로 개발을 진행하는 방식이다. 모든 개발을 stage 브랜치에서 진행하고 실제로 main에 병합하는 방식을 선택했다.
TBD는 하나의 브랜치로 개발을 진행하는 방식이였는데, QA를 위해서 2개의 브랜치를 사용했다.
이러한 방식을 선택하게 되면 문제가 기존의 feature브랜치처럼 기능을 미리 개발하고 나중에 추가하는 방식을 사용할 수는 없다.
-
feature flage (feature toggle)
코드 자체에서 기능 분기를 유연하기 관리하는 대안이다. 각 가능들을 전환하고 숨기거나 비활성화 및 활성화를 상당히 유연하게 할 수 있어서, git-flow와 같이 여러 기능들의 브랜치를 추가하거나 삭제하거나 하는 방식보다 개발자가 직관적으로 개발을 하기가 좋앗다.
아래와 같이 버전을 관리할때 용이하게 사용할 수 있다.
featureFlag.ts
와 같이 각 기능들별로 관리를 용이하게 할 수 있고, 해당 기능들의 버전또한 하나의 파일로 관리를 할 수 있다.featureFlag.tsexport const pageFlag = { helloPage : { featureA: true, featureB: false, } } export const featureFlag = { featureA: { v1: true, v2: false, }, featureB: { v1: true, v2: false, }, }
helloPage.tsxif (pageFlag.helloPage.featureA) { if (featureFlag.featureA.v2) { // v2 featureA } else if (featureFlag.featureA.v1) { // v1 featureA } } else if (pageFlag.helloPage.featureB) { // helloPage featureB }
예시의 경우 조건문을 여러번 사용했지만, 어떤식으로 사용하냐에 따라 커스텀 훅을 만들어서 각 컴포넌트를 렌더링하면 쉽게 할 수 있다.
이 방식을 도입하고 좋았던 점으로, 오래된 기능을 삭제하고, 브랜치또한 제거했던 기능을 갑자기 다시 추가하는 경우가 있었는데 위와 같이 코드를 삭제된 코드를 관리하기 쉬워졌다.
Reference
[1] "우린 Git-flow를 사용하고 있어요" 우아한기술블로그 "2017.10.30" https://techblog.woowahan.com/2553/
[2] trunkbaseddevelopment https://trunkbaseddevelopment.com/