Trunk-based Development는 소프트웨어 개발에서 사용되는 워크플로우로, 모든 개발자가 코드베이스의 단일 브랜치(일반적으로 main 또는 trunk라고 불림)에서 짧은 생명주기를 가진 브랜치를 사용하여 작업하는 방식입니다.
이 접근 방식은 빈번한 통합, 빠른 반복, 그리고 지속적인 배포를 장려합니다.
Gitflow와 비교하여 특징
최근 트렌드에서 Gitflow는 여전히 복잡한 릴리스 관리가 필요한 프로젝트에 유용하지만, 빠른 개발 사이클과 지속적인 배포를 추구하는 DevOps 문화에서는 Trunk-based Development와 같은 더 단순하고 빠른 통합을 지원하는 워크플로우가 선호되고 있습니다.
Gitflow의 단점
-
복잡성: 여러 종류의 브랜치(feature, develop, release, hotfix, master)를 관리해야 하므로, 브랜치 관리가 복잡해질 수 있습니다.
-
느린 통합 속도:
feature브랜치가develop또는release브랜치로 병합되기까지 시간이 걸릴 수 있으며, 이는 통합 속도를 늦출 수 있습니다. -
지속적인 배포에 어려움: 릴리스 준비 과정이 명확하게 분리되어 있어 지속적인 배포(CD) 환경을 구축하기가 더 복잡할 수 있습니다.
Trunk-based Development의 장점
-
단순성: 모든 개발 작업이
trunk또는main브랜치에서 이루어지므로 브랜치 관리가 단순해집니다. -
빠른 통합 및 배포: 짧은 생명주기의 브랜치를 사용하고, 자주
trunk에 병합함으로써 지속적인 통합(CI)과 배포(CD)를 촉진합니다. -
향상된 협업 및 빠른 피드백: 모든 개발자가 같은 브랜치에서 작업함으로써 협업이 강화되고, 문제를 빠르게 발견하고 해결할 수 있는 빠른 피드백 루프가 형성됩니다.
-
배포 준비 상태 유지:
trunk브랜치가 항상 배포 가능한 상태를 유지하도록 요구함으로써, 언제든지 새로운 기능이나 수정 사항을 생산 환경에 적용할 수 있습니다.
Trunk-based Development를 위해 지켜야할 핵심 규칙
1. trunk 또는 main 브랜치를 항상 배포 가능한 상태로 유지
모든 코드 변경 사항은 trunk 브랜치에 직접 병합되기 전에 테스트를 거쳐야 합니다. 이는 trunk 브랜치가 언제나 안정적이고 배포 가능한 상태를 유지하도록 보장합니다.
2. 짧은 생명주기의 브랜치 사용
기능 개발이나 버그 수정을 위한 브랜치는 가능한 한 짧은 기간 내에 trunk에 병합되어야 합니다. 일반적으로 이러한 브랜치의 생명주기는 하루에서 며칠 정도입니다.
3. 지속적인 통합(CI)
코드 변경 사항을 자주 trunk에 병합하고, 각 병합마다 자동화된 테스트를 실행하여 코드의 품질을 지속적으로 검증합니다.
4. 피처 토글
대규모 기능 개발이 필요한 경우, 피처 토글을 사용하여 기능을 비활성화 상태로 trunk에 병합할 수 있습니다. 이를 통해 기능이 완전히 준비될 때까지 사용자에게 노출되지 않도록 관리할 수 있습니다.
5. 충돌 해결에 대한 명확한 전략
자주 발생하는 병합으로 인해 충돌이 발생할 수 있습니다. 팀 내에서 충돌을 효율적으로 해결하기 위한 명확한 전략과 규칙을 마련해야 합니다.
6. 코드 리뷰와 품질 관리
코드의 품질을 유지하기 위해, 병합 전에 코드 리뷰를 실시하는 것이 중요합니다. 또한, 코드 표준과 베스트 프랙티스를 준수하여 개발해야 합니다.
7. 지속적인 배포(CD)
trunk에서의 변경 사항은 지속적으로 배포 준비 과정을 거쳐야 합니다. 이를 위해 자동화된 배포 파이프라인을 구축하고 유지 관리하는 것이 중요합니다.
