트렁크 기반 개발

트렁크 기반 개발의 이점

트렁크 기반 개발은 지속적 통합을 위한 필수 관행이 되었습니다. 빌드 및 테스트 프로세스가 자동화되어 있지만 개발자가 공유 브랜치에 자주 통합되지 않는 격리되고 오래된 기능 브랜치에서 작업하는 경우 지속적 통합은 잠재력을 완전히 활용하지 못합니다.

트렁크 기반 개발은 코드 통합의 마찰을 완화합니다. 개발자가 새 작업을 마치면 새 코드를 메인 브랜치에 병합해야 합니다. 하지만 성공적으로 빌드할 수 있다는 것을 확인하기 전까지는 트럭에 변경 사항을 병합하지 말아야 합니다. 이 단계에서 새 작업이 시작된 이후에 수정이 이루어지면 충돌이 발생할 수 있습니다. 특히 개발 팀이 성장하고 코드베이스가 확장되면서 충돌은 점점 더 복잡해집니다. 개발자가 소스 브랜치에서 벗어난 별도의 브랜치를 만들고 다른 개발자가 겹치는 코드를 동시에 병합할 때 발생합니다. 다행히 트렁크 기반 개발 모델로 이 충돌을 줄일 수 있습니다.

지속적 코드 통합 가능

트렁크 기반 개발 모델에는 커밋이 꾸준히 메인 브랜치로 흐르는 리포지토리가 있습니다. 이 커밋 스트림에 자동 테스트 스위트와 코드 검사 모니터링을 추가하면 지속적 통합이 가능합니다. 새 코드가 트렁크에 병합되면 자동 통합과 코드 검사 테스트가 실행되어 코드 품질을 검증합니다.

지속적인 코드 검토를 보장

트렁크 기반 개발의 빠르고 작은 커밋으로 코드 검토 프로세스의 효율성을 높여줍니다. 브랜치가 작으면 개발자가 작은 변경 사항을 빠르게 확인하고 검토할 수 있습니다. 검토자가 코드 페이지를 읽거나 코드 변경의 넓은 영역을 수동으로 검사하는 수명이 긴 기능 브랜치보다 훨씬 더 쉽습니다.

연속 프로덕션 코드 릴리스를 지원

팀은 매일 메인 브랜치에 자주 병합해야 합니다. 트렁크 기반 개발은 트렁크 브랜치를 어떤 커밋에서든 배포할 준비가 되었다는 뜻인 “초록색”으로 유지하기 위해 노력합니다. 자동 테스트, 코드 검사, 코드 검토 덕분에 트렁크 기반 개발 프로젝트에는 언제든지 프로덕션에 배포할 수 있다는 보장이 있습니다. 이것은 프로덕션에 자주 배포하고 일일 프로덕션 릴리스의 추가 목표를 설정할 수 있는 애질리티를 팀에 제공합니다.

트렁크 기반 개발 및 CI/CD

CI/CD의 인기가 높아지면서 브랜칭 모델이 개선되고 최적화되어 트렁크 기반 개발이 떠올랐습니다. 이제 트렁크 기반 개발은 지속적 통합의 요구 사항이 되었습니다. 지속적 통합으로 개발자는 트렁크 기반 개발을 각 커밋 후 실행되는 자동 테스트와 함께 수행합니다. 그러면 프로젝트가 항상 작동하도록 보장됩니다.

트렁크 기반 개발 모범 사례

트렁크 기반 개발을 통해 팀이 코드를 빠르고 일관되게 릴리스할 수 있습니다. 팀의 주기를 다듬고 최적화된 릴리스 일정을 수립할 수 있는 연습 및 관행의 목록은 다음과 같습니다.

소규모 배치로 개발

트렁크 기반 개발은 빠른 리듬에 따라 코드를 프로덕션에 전달합니다. 트렁크 기반 개발이 음악이었다면 짧고 간결한 음표가 연속으로 이어지는 빠른 스타카토이고 리포지토리 커밋이 음표일 것입니다. 커밋과 브랜치를 작게 유지하면 병합 및 배포의 속도를 더 높일 수 있습니다.

커밋 몇 개를 약간만 변경하거나 코드 몇 줄을 수정하면 인지 오버헤드가 최소화됩니다. 제한된 코드 영역을 검토할 때 거대한 변경 사항보다 팀이 의미 있는 대화를 나누고 빠른 결정을 내리는 것이 훨씬 쉽습니다.

기능 플래그

기능 플래그는 개발자가 비활성 코드 경로에 새 변경 사항을 래핑하고 나중에 활성화할 수 있도록 하여 트렁크 기반 개발을 훌륭하게 보완합니다. 이렇게 하면 개발자가 별도의 리포지토리 기능 브랜치를 만드는 과정을 생략하고 그 대신 기능 플래그 경로 내 메인 브랜치에 새 기능 코드를 직접 커밋할 수 있습니다.

기능 플래그는 소규모 배치 업데이트를 직접적으로 유도합니다. 기능 브랜치를 만들고 전체 사양을 구축하기 위해 기다리는 대신, 개발자는 기능 플래그를 도입하고 플래그 내에 기능 사양을 구축하는 새 트렁크 커밋을 푸시하는 트렁크 커밋을 만들 수 있습니다.

종합적인 자동 테스트 구현

CI/CD를 달성하려는 최신 소프트웨어 프로젝트라면 자동 테스트가 필요합니다. 릴리스 파이프라인의 여러 단계에서 실행되는 자동 테스트에는 여러 유형이 있습니다. 단기적인 실행 단위 및 통합 테스트는 개발 중이고 코드 병합 시 실행됩니다. 더 오래 실행되는 풀스택 엔드 투 엔드 테스트는 전체 스테이징이나 프로덕션 환경에 대해 이후 파이프라인 단계에서 실행됩니다.

자동 테스트는 개발자가 새 커밋을 병합할 때 소규모 배치 리듬을 유지하여 트렁크 기반 개발을 지원합니다. 자동 테스트 스위트는 코드에 문제가 있는지 검토한 후 자동으로 승인 또는 거부합니다. 이렇게 하면 개발자가 빠르게 커밋을 만들고 자동화된 테스트를 통해 실행하여 새로운 문제가 생기는지 확인할 수 있습니다.

비동기식 코드 검토 수행

트렁크 기반 개발에서는 코드 검토를 즉시 수행해야 하며 나중에 검토하기 위해 비동기식 시스템에 넣으면 안 됩니다. 자동 테스트는 선제적 코드 검토 계층을 제공합니다. 개발자가 팀원의 풀리퀘스트를 검토할 준비가 되면 먼저 자동 테스트가 통과되었고 코드 커버리지가 증가했는지 확인할 수 있습니다. 이렇게 하면 새 코드가 특정 사양을 충족한다는 확신을 검토자에게 줄 수 있습니다. 그러면 검토자는 최적화에 집중할 수 있습니다.

애플리케이션의 코드 리포지토리에 3개 이하의 활성 브랜치

브랜치가 병합되면 삭제하는 것이 모범 사례입니다. 아쉽게도 활성 브랜치가 많은 리포지토리에는 일부 부작용이 있습니다. 팀이 활성 브랜치를 살펴보고 어떤 작업이 진행 중인지 확인하는 것은 유용할 수 있지만 오래된 비활성 브랜치가 남아 있으면 이 이점을 누리기는 어렵습니다. 일부 개발자는 원격 브랜치를 많이 로드할 때 다루기가 어려워질 수도 있는 Git 사용자 인터페이스를 사용합니다.

적어도 하루에 한 번은 브랜치를 트렁크에 병합

성과가 높은 트렁크 기반 개발 팀은 오픈 브랜치와 병합할 준비가 된 브랜치를 적어도 매일 닫고 합병해야 합니다. 이렇게 하면 리듬을 유지할 수 있고 릴리스 추적의 케이던스를 설정합니다. 그러면 팀은 하루가 끝날 때 메인 트렁크를 릴리스 커밋으로 태그할 수 있는데 매일 애자일 릴리스 증분을 생성한다는 유익한 부수 효과가 있습니다.

코드 정지 횟수 및 통합 단계 감소

애자일 CI/CD 팀은 통합 단계에서 계획된 코드 정지나 일시 중지가 필요하지 않지만 조직에서는 다른 이유로 필요할 수도 있습니다. CI/CD의 “지속적”이란 업데이트가 계속 진행되고 있다는 뜻입니다. 트렁크 기반 개발 팀은 코드 정지를 피하고 릴리스 파이프라인이 멈추지 않도록 적절히 계획을 세워야 합니다.

빠르게 빌드하고 즉시 실행

빠른 릴리스 간격을 유지하려면 빌드 및 테스트 실행 시간을 최적화해야 합니다. 비용이 많이 드는 정적 계산을 피하려면 CI/CD 빌드 도구는 알맞은 경우 캐싱 레이어를 사용해야 합니다. 타사 서비스에 적합한 스텁을 사용하도록 테스트를 최적화해야 합니다.

결론...

트렁크 기반 개발은 단순화된 Git 브랜칭 전략을 사용하여 소프트웨어 릴리스 케이던스를 설정하고 유지하기 때문에 현재 고성능 엔지니어링 팀의 표준입니다. 게다가 트렁크 기반 개발을 통해 엔지니어링 팀은 최종 사용자에게 소프트웨어를 제공하는 방법을 더 유연하게 제어할 수 있습니다.

Atlassian의 Bitbucket에는 트렁크 기반 개발을 지원하는 CI/CD 기능이 내장되어 있습니다. 지금 사용해 보세요.