[TBD] - Trunk Based Develop

 

이전에 진행한 프로젝트에서 멘토님의 추천을 받아 TBD 방식을 채택하여 개발을 진행하였습니다.

혼자 작은 토이 프로젝트를 할 때에도 TBD를 적용하려고 이전에 어떻게 했었지? 생각하다가

TBD 방식에 대한 이해 자체가 부족한 것은 아닌가 싶어서 반성하고 조금 공부해보았습니다!

 

TBD란?

언제든 릴리즈 가능한 Trunk(or Main) 브랜치 위주의 작업 Flow

 

이름 그대로 단일한 브랜치(Main or Trunk) 위주로 작업을 하는 Work Flow입니다.

 

다른 Flow와 무엇이 다른가? 한다면

세부 브랜치 없이 단일한 브랜치(Main or Trunk)에 수시로 병합(merge)한다는 점이 가장 큰 특징일 것 같습니다.

 

아래의 그림처럼 별도의 브랜치에서 작업할 경우 main 브랜치에 병합할 때 마다 작업량이 크기 때문에 부담도 커집니다.

세부 브랜치가 늘어갈수록 이런 부담도 같이 커지겠죠?

그렇다면 브랜치를 줄이고 병합 자체를 작은 단위로 지속적으로 한다면 어떨까요?

 

이런 방법으로 병합의 부담(merge pain)과 Flow 복잡성을 줄이는 것이 TBD의 핵심이라고 할 수 있습니다.

Release 브랜치에 쌓인 작업들..병합이 부담으로 다가온다.(Merge pain)

Release 브랜치 없이 작업

큰 규모의 경우 작은 기능 브랜치(feature) 브랜치를 수시로 병합(merge)한다.

특징

세부적인 브랜치 없이 바로 Trunk에 merge 한다.

- develop이나 release와 같은 세부 브랜치 없이 바로 Trunk(or main) 브랜치에 병합합니다.

 

브랜치의 수명을 가능한 짧게 가져간다.

- 브랜치의 수명이 길어질수록 병합에 대한 부담이 커지기 때문에 브랜치의 수명을 짧게 가져갑니다.

 

Flow의 복잡성이 적어 빠른 진행이 가능하다.

- git flow처럼 develop, release, hotfix 등으로 브랜치를 관리할 경우 관리에 대한 부담이 발생합니다.

- 소규모 프로젝트의 경우 이런 복잡성이 적은 방식은 관리에 대한 부담을 줄이고 빠른 작업을 가능하게 합니다.

 

단점 및 주의사항

merge가 바로 main으로 가기 때문에 실수에 취약하다.

- 세부 브랜치가 없어 작업의 효율성은 올라가지만 동시에 안정성에 취약합니다.

- 그래서 아래와 같은 작업들이 권장됩니다.

 

TDD환경을 갖춰서 안정성을 확보하는 것이 권장된다.

- 테스트 환경을 통해 병합 전 안정성을 확보합니다. 

 

merge전 코드 리뷰가 권장된다.

- 머지 전 동료의 코드 리뷰를 통해 코드의 안정성 및 품질을 확보합니다.

- 참고로 TBD를 소개하는 사이트에서는 eager and continuous code review라고 강조하고 있습니다.

 

빌드 서버를 통해 적용된 커밋이 빌드 에러를 일으키는지 확인하는 것이 권장된다.

- 빌드 서버를 따로 운용해 빌드 에러가 나는 커밋이 병합되지 않도록 확인합니다.

 

 

결론

TBD는 프로젝트 사이즈를 고려하고 여러 절차를 확보하면 빠른 속도감의 효율적인 CI/CD 가능한 방식인 것 같습니다.

혼자 진행하는 작은 프로젝트들에 적용하여 빠르게 작업을 할 수 있을 것 같아 자주 사용할 예정입니다.

 

다만, 아직 테스트 환경 구축에 대한 이해가 높지 않기 때문에

TDD에 대한 이해를 높여서 더 안정적인 작업을 해야할 것 같습니다.

---

참고한 자료들

https://trunkbaseddevelopment.com

Trunk Based Development

https://helloinyong.tistory.com/335

TBD(Trunk Based Development) 전략이란?

https://pgo-dev.medium.com/git-flow-vs-tbd-어떤-버전관리-전략이-유리할까-cd238d3f2ff4

Git-flow vs TBD 어떤 버전관리 전략이 유리할까?