Trunk Based Development(이하 TBD)

1. TBD 란?

흔히 사용하는 git flow 방식의 branch 전략 방식과 반대되는 전략이다.

 

git flow 에선 N명의 개발자들이 feature branch 로 개발하고 PR 을 날려 리뷰하고 개발했다면

 

TBD 에선 PR 하는 대신에 하나의 branch(master or main or trunck) 로 페어(or 몹)프로그래밍을 통해 실시간으로 피드백 & 반영 을 한다. (즉 master branch 에 직접 push)

---

2. 장점 및 해결하고자 하는 문제점?

 

[개인보단 팀]

1. git flow 전략에서의 'PR, Merge 로 인해 발생하는 단점' 을 제거시킴으로써 '팀이 함께 쓰는 코드' 에서 '개인의 책임' 보다 '팀의 책임' 에 더 비중을 둘 수가 있다.

 

(단점 ex) 여유가 없어 리뷰를 꼼꼼히 못하거나, 늦게 PR 을 하는 개발자일 수록 처리할 merge conflict가 많아진 다거나)

 

2. TBD 가 해결하고자 하는 기존의 문제점은 "프로그램이 오래될 수록 발생하는 '코드의 개인화'" 인 것 같다.

 

코드의 개인화를 줄임으로써, 하나의 코드를 팀이 함께 개발함으로써 장기적으로 전체적인 개발 속도를 향상시키고자 하는 것 같다.

 

3. 모두가 그 코드를 알고 있으니 팀의 어느 누가 그 코드를 봐도 '코드를 이해하는데 드는 시간' 이 적을 것이다. 현업에서 가장 시간을 많이 뺏는 것이 '코드의 의도와 쓰임새를 이해하기' 니깐.

 

4. 코드가 항상 master branch 에 업데이트 되므로 진정한 의미의 CI(코드통합) 가 된다.

 

CI와 더불어, 서비스의 지속적인 업데이트(CD)도 가능하므로 CI/CD 에 적합하다.

 

3. TBD 는 만능이 아니다

1. TBD 는 빠른 버전 업데이트에 대한 오류의 허용오차가 높은 경우에 사용하기 적합하다. 

 

ex) 비트코인 거래소가 TBD를 적용해 개발 하는데, 결제 시스템 배포 건에서 버그가 발생해 비트코인을 '1개' 구매했는데 지갑에 '1000개' 가 들어왔다면??

-> 엄청난 금전적 손실이 발생할 것이다. 그러므로 TBD를 적용할 땐 그만큼 오류의 허용오차가 적은 경우 이거나, 충분한 테스트 커버리지를 지녀야 할 것이다.

 

2. TBD는 필수가 아닌 선택이다.

 

즉, CI/CD 의 매력에 빠져 마냥 TBD 를 적용하지 말고, git flow 와 같은 branch 전략들과 비교해 보는 'branch 전략 옵션 중 하나' 로 생각하자.

 

---

결론 : TBD는 CI/CD 에 적합한 branch 전략이지만, 수많은 branch 전략 중 하나일 뿐 만능이 아니라 옵션중 하나일 뿐이다.

 

 

 

참고 :

https://code-masterjung.tistory.com/73

https://www.jetbrains.com/ko-kr/teamcity/ci-cd-guide/concepts/trunk-based-development/