당신에게 트렁크 기반 개발을 추천합니다

저도 여러 조직의 개발팀에 몸담으면서 다양한 브랜치전략을 경험해보았는데요

 

현재 개발 트렌드에 맞춰 제가 가장 선호하는 것은 트렁크 베이스 개발(trunk-based development)이라고 불리는 전략입니다

 

 

 

개발팀이 버전을 관리하기 위해 함께 작업하는데에는 크게 두가지 주요 패턴이 있습니다

 

 

기능별 브랜치

 

하나는 기능별 branch 사용하는 방법입니다

 

이 방법에서는 개발자들이 메인이 되는 기본 브랜치에서 새 브랜치를 만든 다음

 

새로 만드려는 기능이 완료될때까지 해당 브랜치에서 개별적으로 작업합니다

 

그리고 그 기능이 준비가 되었다고 판단되면 해당 브랜치를 기본 브랜치에 병합하는 방법입니다

 

이방법은 하나의 기능브랜치에 여러명의 개발자가 속하기도하고

 

해당 기능의 개발이 짧게는 몇일이 걸릴수도 있지만 길게는 1개월 이상이 걸릴수도 있습니다

 

하지만 단점이 있는데요

 

이 사진이 이 방법론의 단점을 가장 극명하게 보여준다고 생각합니다

 

생성된지 오래된 브랜치일수록 병합시에 충돌이 일어날 가능성이 높습니다

 

개발팀의 규모가 클수록 병렬로 진행되는 브랜치의 수는 더욱 많을것이고

 

각각의 기능 브랜치는 어떤것은 생성된지 짧은것일수도 있고 어떤것은 굉장히 오래된것일수도 있을거예요

 

그럴수록 기본 브랜치에 병합하는 일은 엄청난 이벤트가 됩니다(엄청난 충돌의 연속)

 

 

트렁크 기반 개발

 

두번째 패턴은 트렁크 기반 개발이라고 합니다

 

이 패턴에서는 개발자가 작업을 소규모 배치(작은단위로 쪼갠 태스크)로 나눈 다음

 

해당 작업을 자주(하루에 1번이상) 기본 브랜치에 병합합니다

 

이 방식의 주요 이점은 소규모 병합을 빈번하게 수행하여 

 

대규모 병합을 피하게되고, 머지 작업의 복잡성이 감소하여, 코드를 항상 거의 최신의 상태로 유지할수 있다는 점입니다

 

이 패러다임에서는 개발자는 항상 트렁크라고 불리는 마스터브랜치를 stable한 상태로 유지해야합니다

바로 이런식의 그림이예요

 

UI레이어가 아닌 서비스 또는 API레이어에서 개발이 먼저 시작되고

 

end user가 초기에 사용할수 없는 API가 서버에 먼저 추가되는 형태입니다(다크런칭)

 

기능 플래그(feature flag)를 도입하여 특정 기능의 on/off를 설정합니다

 

UI 요소를 표시하거나 표시하지 않거나, 특정 로직의 사용을 on/off하거나 말이죠

 

 

 

트렁크 기반 개발 방법은 애자일 / 지속적 통합이라는 개발 문화와 잘 어울립니다

 

 

 

 

이 방법을 채택하려면 다음과 같은 사항들을 고민하셔야 합니다

 

소규모 배치로 개발합니다

소규모 배치로 개발을 하면 변경사항에 대한 피드백을 받는데 걸리는 시간이 단축됩니다

많은 양의 코드는 리뷰에 더욱 많은 시간이 걸립니다

100줄의 코드가 10분이 걸린다면 1000줄의 코드는 10배인 100분이 아니라 훨씬 많은 시간이 필요합니다

빠르게 작업된 코드가 트렁크에 통합될수 있도록 하세요

코드 검토과정이 복잡하지 않도록 합니다

코드 리뷰 과정이 복잡하면 복잡할수록 개발자는 그 복잡함을 피하기 위해

작은 10개의 일을 10번의 코드 검토를 요청하지 않고 크게 1개로 만들어서 코드 검토를 요청하게 됩니다

즉 코드검토를 미루게 되는 현상이 발생합니다

빠르게 작업된 코드가 트렁크에 통합될수 있도록 하세요

 

코드검토를 최우선으로 합니다

하나의 코드가 검토되고있는 동안에 새로운 작업이 시작되면 안됩니다

병합이 지연될수록 문제가 발생할 가능성이 높습니다

서로의 코드를 우선적으로 검토하는 팀의 합의가 있어야 합니다

다른 사람의 코드를 우선적으로 검토하여 변경사항이 트렁크에 최대한 빠르게 병합되도록 합니다

 

코드 테스트 자동화

트렁크가 항상 안정적인 상태를 유지하려면 테스트가 병행되어 푸시한 코드가 기본적인 안정성을 통과하였음을 보장할수록 좋습니다

 

 

 

 

참고 :

https://launchdarkly.com/blog/git-branching-strategies-vs-trunk-based-development/

https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development?hl=ko