트렁크 기반 개발은 지속적 통합 및 지속적 전달/배포(CI/CD)를 수행하는 팀에서 자주 사용되는 다양한 브랜치 전략 중 하나입니다.
트렁크 기반 개발을 활용하면 마스터 브랜치(즉, 트렁크)에 변경 사항을 직접 커밋하므로 별도의 브랜치에서 기능을 개발하고 버그를 수정한 후 마스터 브랜치에 병합하지 않아도 됩니다.
마스터 브랜치에 변경 사항을 커밋하면 CI/CD 파이프라인이 트리거됩니다. 파이프라인에서 오류가 표시될 경우 모두가 최대한 신속한 문제 해결을 위해 나서야 합니다. 이 방식의 목표는 변경 사항을 자주 릴리스하면서 마스터 브랜치를 배포 가능한 상태로 유지하는 것입니다.
CI/CD 원칙을 이미 잘 알고 계신다면 앞서 설명된 트렁크 기반 개발이 지속적 통합 및 배포에 적합하다는 사실을 인식하셨을 겁니다. 모든 팀원이 정기적으로 변경 사항을 커밋하면 모든 변경 사항을 가시적으로 확인하고 진행 중인 개발 내용에 수시로 신속한 피드백을 얻을 수 있습니다.
마스터 브랜치를 안정적이고 릴리스 가능한 상태로 유지하는 것이 가장 중요하므로 모든 팀원은 개발 과정에서 변경 사항에 대한 테스트를 추가하도록 권장됩니다. 테스트 커버리지 지표 모니터링을 통해 이에 주의를 기울일 수 있으며, 모든 팀원은 커밋하기 전 로컬로 빌드(기본 자동화 테스트 세트 실행)하여 마스터 브랜치에서 발견되는 이슈를 줄일 수 있습니다.
트렁크 기반 개발을 선호하는 분들 중 일부는 트렁크 기반 개발만이 지속적 통합을 달성하는 유일한 방법이며, 개발 또는 피처 브랜치를 사용하면 CI/CD의 이점이 사라질 뿐이라고 주장합니다. 그러나 트렁크 기반 개발에도 단점이 있습니다.
이 개발 방식은 파이프라인의 모든 단계를 통과한 코드 변경 사항이 자동으로 릴리스되는 지속적 배포에 적합하지만, 이 모델을 가장 적절히 활용할 수 있는 분야는 지속적 업데이트에 대한 허용 오차가 높으며, 지속적 업데이트가 예상되는 SaaS 제품입니다.
설치된 제품이나 모바일 앱을 빌드하는 경우 파이프라인을 통해 업데이트가 제공될 때마다 새 버전을 제작하지 않고, 정기적 릴리스로 변경 사항을 일괄 처리하는 것이 좋습니다.
이 경우 브랜치를 사용하면 더욱 간편하게 각 릴리스에 포함된 기능을 관리하고, 여러 제품 버전을 위한 지속적 지원을 제공할 수 있습니다.
트렁크 기반 개발의 잠재적 문제는 복잡한 대규모 기능의 개발 방식과 관련이 있습니다. 변경 사항을 정기적으로 마스터에 커밋하면서 프로덕션에 바로 배포하려면, 사용자에게 공개하지 않는 기능을 관리할 방법을 구상해야 합니다.
트렁크 기반 개발에서는 기능 플래그를 통해 기능 표시 여부를 관리할 수 있지만 이러한 관리 방식은 까다로울 수 있습니다. 이에 대한 대안으로, 피처 브랜치를 포함하는 브랜치 전략을 선택하면 기능을 릴리스할 준비가 될 때까지 별도 관리가 가능합니다.
CI/CD를 처음 사용하는 팀의 경우 강력한 테스트 제품군을 개발하기 전에 변경 사항을 마스터에 직접 커밋하고 배포 가능한 상태로 유지하는 데 어려움을 겪을 수 있습니다. 그럼에도 트렁크 기반 개발이 적합한 경우 CI/CD 관행의 발전과 함께 이 개발 방식을 시도해볼 가치가 있습니다.
트렁크 기반 개발은 지속적 통합 및 배포와 함께 사용하기 적합합니다. 이 방식은 강력한 자동화 테스트 제품군을 갖추고 여러 버전의 소프트웨어를 지원하거나 릴리스에 따라 업데이트를 구분할 필요가 없을 때 가장 잘 작동합니다. 하지만 이 방식만이 유일한 방법은 아니며, 상황에 따라 다른 브랜치 전략이 더 적합한 경우도 있습니다.