이제 git flow는 그만 TBD를 도입해보자.

안녕하세요. 이번 블로그 포스팅으로 다룰 내용은 TBD입니다. 기존에 제가 많은 프로젝트를 하면서 git flow 형식을 많이 사용을 했었습니다. 하지만 최근 들어서 조금 안정화가 된 프로젝트와 규모가 커진 서비스들이 자리를 잡으면서 유지보수 방면에 있는 서비스 플랫폼들도 존재합니다. 여기서 주변 개발자 지인분들이 TBD를 도입하면 좋을 것 같다.라고 말씀을 해주셔서 "TBD가 뭘까?" 궁금해져서 찾아보게 되었습니다.

 

먼저 시작하기에 앞서서 평소에도 자주 사용하는 branch 전략인 git-flow 전략을 간단히 설명해 보겠습니다.

 

Git-Flow?

우리가 흔히 자주 사용하는 branch 전략 기법 중 하나가 깃 플로우(git flow)라는 것인데, 주로 중대형

프로젝트에서 적합한 전략으로 병렬 개발을 위한 전략으로 주로 사용이 됩니다.

 

Git-flow의 병렬 개발?

여러 개발자가 동시에 다른 기능 또는 버그 수정 작업을 진행할 수 있는 상태를 의미합니다.
즉, feature 브랜치를 통하여 각각의 개발 작업을 별도의 브랜치에서 진행한다. ➡️ 독립적

 

보통 develop에서 시작하고 트리 구조로 퍼지는 형태로 나뉘게 되죠.

 

각각의 팀원들이 develop에서 시작되는 여러 브랜치들을 작업을 통해서 이뤄지다가 각각의 작업물이 끝나게 된다면, develop에 merge를 하고 그다음에 main 또는 master 브랜치에 Deploy를 하는 경우가 대다수이죠. 이를 통해서 릴리즈를 통한 배포도 하기도 하고요. 이런 기법을 이제 우리는 git flow라고 부르기로 합니다.

 

이러한 git flow는 다음 아래와 같은 특징을 가지고 있습니다.

 

특징	내용
긴 수명 주기 브랜치 기반의 작업 흐름	유지보수, 버그 수저오가 같은 장기적인 작업을 위해서 사용
주요 브랜치와 보조 브랜치	master(main), develop을 통한 브랜치 사용, (feature, release, hotfix)와 같은 보조 브랜치를 사용
엄격한 브랜치 정책	각각의 브랜치의 특정한 목적을 가지고 그에 따른 브랜치 정책
롤백을 위한 태그	릴리즈 브랜치에서 릴리스 태그를 표시하여 롤백 용이
긴급한 버그 수정과 유지보수에 유용	hotfix 브랜치를 통해 긴급 버그 수정, 유지보수가 가능

 

TBD란 무엇일까?

TBD는 Trunk-Based Development라는 약자입니다.

 

TBD 방식은 간단하게 설명을 하자면, 언제든지 릴리즈가 가능한 상태인 Trunk라는 브랜치가 존재를 하고, 거기서 모든 개발자들이 자기의 작업을 진행하면서 Trunk 브랜치에 commit을 하는 형태를 이야기합니다.

 

(하위 브랜치가 없이 바로 Trunk 브랜치에 (기능을 추가) merge를 하기 때문에 큰 문제들이 발생할 수 있다.)

 

그러기 때문에 Trunk 브랜치에서 개발자들과 서로 브랜치 내부에 대한 내용이나, 코드 에러, 스타일이 확인이 되어야 하고, 이러한 문제들을 서로 검수한 다음에, 커밋 반영이 되어도 문제가 없다.라고 판단이 되면 실제로 반영을 하는 시스템입니다.

 

그러면 TBD가 되기 위해서 어떤 요소들이 필요로 할까?

많은 블로그들을 보면서 가장 많이 중요하다고 생각하는 요소가 약 3개 정도 있었습니다.

 

1. 자동화 빌드 : 실시간 빌드를 통해 에러가 없는지 확인하고, 실제 반영이 될 수 있도록 한다.
2. TDD : TDD 방식을 통해서 테스트 코드의 확인과 Trunk 브랜치 반영 전 기능적 에러 발생을 최대한 분석(파악) 조치를 한다.
3. 실시간 코드 리뷰, 페어 프로그래밍 : 페어 프로그래밍을 통한 팀원들과 코드를 함께 작업을 하기 때문에 코드 사항에 서로 공유가 되고 코드 리뷰 절차가 없어집니다. 또는 기능 개발을 하는 즉시 바로 리뷰 요청을 하여서 리뷰에 대한 검토를 1순위로 할 수도 있습니다.

더 자세한 TDD 내용은 저의 블로그를 가시면 확인하실 수 있습니다!

TDD에 대해서 알고 있어?

 

Trunk 브랜치 전략에서 코드 리뷰, 페어 프로그래밍의 기능적 에러나 결함이 없는지 검수가 되지 않은 채 바로 Trunk 브랜치에 반영을 하는 것은 절대 TBD 전략이 아니다.

 

그래서 결국에는 궁극적인 목표는 이 TBD라는 개념을 도입을 하여서 Trunk 브랜치에서 안정적이며 빠르게 개발을 할 수 있게 도와주는 그러한 개념인데, 팀원들이 최대한 동일한 코드 상태로 유지가 되도록 하는 기법입니다. 하지만 여기서 여러 문제들이 직면할 수도 있겠죠. 제가 처음에는 작은 규모의 프로젝트나 서비스이면 자주 사용을 한다고 하였는데, 인원도 많아지고 어떠한 코드에 대한 에러 처리도 더 많이 생길 수도 있을 것 같다고 생각이 들었습니다. 

 

그러면 이러한 환경에서는 어떻게 구축을 해야 할까요?

 

STBD라는 것이 등장했다.

앞서 말을 했다시피 규모도 커지고 서비스도 확대가 되면 즉각적으로 코드 리뷰를 하는 것이 어려움이 있을 수도 있고, 또는 페어 프로그래밍으로 실행이 안 될 수도 있다고 생각이 들어서, 이러한 Trunk 브랜치의 전략은 살리되 조금 더 안정화시킬 수 있는 기법이 업그레이드가 되었다. 그건 바로 STBD라는 것인데 여기서 S는 "Scaled"라는 의미를 가지고 있다. 말 그래도 확장된. 브랜치가 하나 더 추가가 된 상태가 된 것이다.

 

STBD는 상위 Trunk 브랜치에서 하위 Feature 브랜치를 생성하여 사용을 하는데, 본 브랜치는 Trunk 브랜치에 반영을 하기 전에 테스트와 충분한 리뷰 검토가 거친 뒤에 반영이 되는 브랜치라고 생각하면 이해하기 편하다.

 

그럼 여기서 궁금증이 생길 것이다. "그러면 git-flow랑 똑같은 거 아니야? 그냥 develop인데?"

나도 처음에 그런 줄 알았다. 하지만 STBD라는 개념은 git-flow의 하위 develop 브랜치와 다르게 생명 주기가 매우 정말 짧다는 것이다.

조금 더 자세히 설명을 해보자.

가장 쉽게 이야기를 하면 git flow는 총 5단계의 브랜치가 존재합니다.

1. main(master)
2. develop
3. release
4. feature
5. hotfix 

기본적으로 git flow는 feature 브랜치를 작업 이후에 develop에 merge를 합니다. 그리고 그 develop을 release라는 브랜치를 통해서 실제로 main(master)에 적용을 해도 되는지 확인을 합니다. 만약 에러가 생기지 않고, 결함이 없다면 merge를 합니다. 그리고 난 이후에 실제 서비스에서 생긴 에러나 버그를 hotfix를 통하여 고칩니다. 이러한 방법이 주로 git flow 방식입니다.

하지만 TBD는 main(master) 브랜치에서 바로 feature 브랜치를 파서 작업을 하고 merge를 합니다. 실제로 release라는 브랜치의 개념도 존재하지만, 잘 사용을 안 한다고 합니다. 하지만 이러한 feature 브랜치를 바로 main(master)에 merge 하면 테스트용, 에러 확인이 비효율적이라고 해서 STBD라는 개념이 존재해서 기존에 git flow의 feature 브랜치였다면 STBD에서는 feature에서 더 아래로 feature(1), feature(2) 나뉘게 되는 것이죠.

조금 더 이해하기 쉽기 생각하면, git flow에서 feature/auth는 auth 파트 전체를 나타내는 것이고, STBD에서는 feature/auth에서 더 세부적인 브랜치로 데이터 받기, 데이터 보내기, 데이터 수정하기 등 더 생명 주기가 짧은 브랜치를 만들어 feature로 만들어서 main(master)로 보내는 형식입니다!

 

Trunk 브랜치에 바로 반영을 해야 하기 때문에 한 번에 할 내용들을 잘 쪼개서 하는 것이 중요하다. Trunk 브랜치에 반영이 되어도 브랜치의 결함이 없도록 하기 위해서 여러 번 고민을 해야 한다.

 

 

Trunk Based Development가 더 궁금하다면!? 🔻

What is Trunk-Based Development?

 

 

 

나의 생각

내가 늘 git flow를 사용하면서 느낀 점은 서비스의 규모가 커지면 커질수록 오버헤드가 자주 발생을 하는데, 여러 브랜치들이 하나로 모이기 때문에 합쳐지는 브랜치들로 인한 merge conflicts도 자주 발생하고 또 feature 브랜치가 굳이 바로 release가 되어야 하나? 근데 develop에 Deploy를 해야 하나 라는 생각도 자주 들었던 것 같다. 근데 솔직히 안정성이나 규모의 앞으로의 전망을 생각하며 프로젝트를 할 때 git-flow가 더 좋다고 느껴지지만, 규모가 작고 바로바로 확인이 가능한 그러한 사이드 프로젝트라면 TBD를 도입해 보는 것도 좋을 것 같다.