2021년 State of DevOps 설문조사에 참여하여 소프트웨어 배포의 미래를 설계하고 의견을 들려주세요.

DevOps 테크: 트렁크 기반 개발

개발자팀이 버전 제어를 사용하여 함께 작업하는 데에는 두 가지 주요 패턴이 있습니다. 하나는 기능 분기를 사용하는 것입니다. 이 패턴에서는 개발자 또는 개발자 그룹이 트렁크(기본 또는 기본 라인이라고도 함)에서 분기를 만든 다음, 빌드하는 기능이 완료될 때까지 해당 분기에서 개별적으로 작업합니다. 팀에서 기능이 제대로 준비가 되었다고 판단하면 기능 분기를 트렁크에 병합합니다.

두 번째 패턴은 트렁크 기반 개발이라고 합니다. 이 패턴에서는 각 개발자가 작업을 소규모 배치로 나눈 다음 해당 작업을 하루 한번 이상(여러 번 가능) 트렁크에 병합합니다. 이러한 접근 방식의 주요 차이점은 범위입니다. 기능 분기에는 일반적으로 여러 개발자가 관여하며 며칠, 심지어 몇 주가 소요됩니다. 반대로 트렁크 기반 개발에서는 많은 개발자들이 개별 변경사항을 트렁크에 자주 병합하므로 분기가 일반적으로 몇 시간 이상 지속되지 않습니다.

다음 다이어그램은 일반적인 트렁크 기반 개발 타임라인을 보여줍니다.

버전 1.0에서 버전 1.1의 트렁크로 병합된 버그 수정을 보여주는 버전 1.0 및 1.1의 타임라인

트렁크 기반 개발에서 개발자는 코드를 트렁크에 직접 푸시합니다. 출시 분기에서 변경된 사항(출시 준비가 된 코드의 스냅샷)은 일반적으로 가능한 빨리 트렁크에 다시 병합됩니다(아래쪽 화살표로 표시됨). 이 접근방식에서는 버그 수정을 선별하여 출시 분기에 병합(위쪽 화살표로 표시됨)해야 하는 경우가 있지만, 이러한 경우는 트렁크에서 새로운 기능의 개발만큼 자주 발생하지 않습니다. 하루에 여러 번 출시되는 경우 변경사항을 트렁크에 직접 푸시하여 배포할 수 있으므로 출시 분기가 전혀 필요하지 않습니다. 트렁크 기반 접근방식의 주요 이점은 개발 라인을 줄이고 소규모 병합을 빈번하게 수행하여 이벤트를 병합하는 데 따른 복잡성이 감소하고 코드를 최신 상태로 유지할 수 있다는 것입니다.

반대로 다음 다이어그램은 트렁크를 기반으로 하지 않은 일반적인 개발 스타일을 보여줍니다.

병합 충돌로 제품 출시가 지연될 수 있는 복잡한 병합 경로와 여러 지점을 보여주는 여러 장기 지속 분기의 타임라인

이 접근방식에서는 개발자가 장기 지속 분기를 변경합니다. 이러한 변경에는 트렁크 기반 개발에 비해 더 복잡한 대규모 병합 이벤트가 필요합니다. 또한 대규모 병합 시 종종 버그 또는 회귀가 발생하므로 이 접근방식에서는 소프트웨어를 작동 상태로 유지하기 위한 추가적인 안정화 작업과 '코드 잠금' 또는 '코드 고정' 기간이 필요합니다. 결과적으로 병합 후 코드를 철저하게 테스트하고 종종 버그를 수정해야 합니다.

트렁크 기반 개발 구현 방법

트렁크 기반 개발은 지속적 통합을 위한 필수사항입니다. 지속적 통합(CI)은 트렁크 기반 개발 작업과 시스템의 상시 작동을 유지하기 위해 트렁크로 커밋 후 자동으로 신속하게 실행되는 일련의 테스트를 유지관리하는 작업의 결합입니다.

지속적 통합의 주요 특징은 소규모 코드 배치를 자주 통합하여 긴 통합 및 안정화 단계를 없애는 것입니다. 이렇게 하면 개발자는 수행 중인 작업에 대해 의사소통할 수 있고 통합 시 다른 개발자와 테스터에게 상당한 작업을 유발할 수 있는 대규모 병합을 피할 수 있습니다.

CI 패러다임에서 빌드 프로세스를 그린, 즉 준비 및 실행 상태로 유지하는 것은 개발자의 책임입니다. 다시 말해 CI 프로세스가 실패하는 경우 개발자는 수행 중인 작업을 중단하고 문제를 즉시 수정하거나 즉시 수정할 수 없다면 변경사항을 되돌려야 합니다.

트렁크 기반 개발을 수행하려면 개발자가 작업을 소규모 배치로 나누는 방법을 이해해야 합니다. 이는 이런 식으로 작업하는 데 익숙하지 않은 개발자에게 큰 변화입니다.

2016년(PDF) 및 2017년(PDF)의 DORA(DevOps Research and Assessment) 데이터 분석 결과 팀에서 다음 관행을 따를 경우 더 높은 수준의 소프트웨어 배포 및 운영 성능(배포 속도, 안정성, 가용성)을 실현할 수 있음을 보여줍니다.

  • 애플리케이션의 코드 저장소에 3개 이하의 활성 분기를 유지합니다.
  • 하루 한번 이상 분기를 트렁크에 병합합니다.
  • 코드를 고정하지 않으면 통합 단계를 수행하지 않습니다.

일반적인 문제

트렁크 기반 개발을 완전히 채택하는 데 장애가 되는 몇 가지 주요 문제는 다음과 같습니다.

  • 코드-검토 절차가 매우 복잡합니다. 많은 조직에는 변경사항을 트렁크에 병합하기 전에 여러 승인 단계가 필요한 복잡한 코드 검토 절차가 있습니다. 코드 검토에 많은 노력이 필요하고 오랜 시간이 걸리는 경우 개발자는 소규모 배치 작업을 피하고 많은 변경사항을 일괄 처리하게 됩니다. 이렇게 되면 검토자가 복잡성으로 인해 대규모 코드 검토를 미루게 되는 하향곡선이 나타나게 됩니다.

    결과적으로 개발자가 병합 요청을 피하게 되므로 병합 요청이 종종 약화됩니다. 검사를 통해 대규모 변경이 시스템에 미치는 영향을 추론하기가 쉽지 않으므로 검토자가 결함을 찾기 어려워지고 트렁크 기반 개발의 이점이 줄어들게 됩니다.

  • 코드 검토가 비동기적으로 수행됩니다. 팀에서 페어 프로그래밍을 수행하는 경우 다른 사람이 코드를 이미 검토한 것입니다. 추가 검토가 필요한 경우 동기적으로 수행해야 합니다. 즉, 개발자가 코드를 커밋할 준비가 되면 다른 팀원에게 코드를 즉시 검토하도록 요청해야 합니다. 예를 들어 요청을 도구에 제출한 다음 검토를 기다리는 동안 새로운 작업을 시작하는 것과 같이 비동기적인 검토를 요청하지 않아야 합니다. 병합이 지연될수록 병합 충돌 및 관련 문제가 발생할 가능성이 높습니다. 동기식 검토를 구현하려면 다른 작업보다 서로의 코드를 우선적으로 검토하도록 하는 팀의 합의가 있어야 합니다.

  • 코드 커밋 전에 자동 테스트를 실행하지 않습니다. 트렁크가 작동 상태를 유지하려면 필수적으로 커밋 전에 코드 변경사항에 대해 테스트를 실행해야 합니다. 이는 개발 워크스테이션에서 수행할 수 있으며, 많은 도구에서 로컬 변경사항에 대해 원격 테스트를 실행한 다음 테스트에 통과했을 때 자동으로 커밋하는 기능을 제공합니다. 개발자가 복잡한 절차 없이 코드를 트렁크에 삽입할 수 있다는 것을 알게 되면 결과적으로 소규모 코드 변경이 발생하므로 이해, 검토, 테스트가 용이해지고 프로덕션으로 손쉽게 이동할 수 있게 됩니다.

트렁크 기반 개발 개선 방법

앞에서 논의한 바와 같이 트렁크 기반 개발을 개선하기 위해 구현할 수 있는 몇 가지 관행이 있습니다.

  • 소규모 배치로 개발합니다. 트렁크 기반 개발의 가장 중요한 요인 중 하나는 소규모 배치로 개발하는 방법을 학습하는 것입니다. 이를 위해서는 개발팀에 대한 교육과 조직의 지원이 필요합니다.
  • 동기식 코드 검토를 수행합니다. 앞서 논의한 대로, 동기식 코드 검토를 진행하거나 개발자가 코드 검토를 우선적으로 지정하도록 하면 변경사항이 트렁크에 병합되기까지 오랜 시간을 대기할 필요가 없습니다.
  • 포괄적인 자동 테스트를 구현합니다. 포괄적이고 유의미한 자동화된 단위 테스트 모음이 있어야 하고 커밋 전에 실행되어야 합니다. 예를 들어 GitHub를 사용하는 경우 모든 테스트를 통과했을 때 pull 요청 병합만 허용하도록 분기를 보호할 수 있습니다. GitHub 검사를 사용하여 빌드 실행 가이드에서는 GitHub 검사Cloud Build를 통합하는 방법을 보여줍니다.
  • 빠르게 빌드합니다. 빌드 및 테스트 프로세스는 몇 분 내에 실행되어야 합니다. 그렇게 할 수 없다면 시스템 아키텍처에 개선할 여지가 있다는 것을 의미합니다.
  • 후원자 및 멘토로 구성된 핵심 그룹을 만듭니다. 트렁크 기반 개발은 많은 개발자에게 상당한 변화이며 일부 저항이 발생할 수 있습니다. 많은 개발자들은 이런 방식으로 작업하는 것을 쉽게 생각하지 못합니다. 좋은 방법은 이런 방식으로 작업해 본 경험이 있는 개발자를 찾아서 다른 개발자를 코칭하도록 하는 것입니다. 또한 일부 팀을 트렁크 기반 스타일로 작업하도록 전환하는 것이 중요합니다. 이렇게 하려면 우선 트렁크 기반 개발 경험이 있는 개발자를 모아서 최소 1개의 팀이 트렁크 기반 개발 방법을 따르도록 하는 것입니다. 그런 다음 이 방법을 따르는 팀이 예상대로 업무를 수행하고 있다는 확신이 들 때 다른 팀도 이러한 스타일로 전환할 수 있습니다.

트렁크 기반 개발 측정 방법

다음을 수행하여 트렁크 기반 개발의 유효성을 측정할 수 있습니다.

테스트 요소 측정 항목 목표
애플리케이션 코드 저장소의 활성 분기. 애플리케이션 저장소의 버전 제어 시스템에 있는 활성 분기 수를 측정하고 이 수를 모든 팀원에게 보이도록 합니다. 그런 다음 목표 상태에 대한 진행상황을 추적합니다. 3개 이하의 활성 분기.
코드 고정 기간. 팀이 보유한 코드 고정 수와 지속 기간을 측정합니다. 이러한 측정을 통해 병합 충돌, 코드 고정, 안정화 등에 소요된 시간도 분류할 수 있습니다. 코드를 제출할 수 없는 경우 코드 고정 없음.
분기 및 포크를 트렁크에 병합하는 빈도. 병합되는 각 분기의 바이너리(예/아니요) 값을 측정하거나 매일 병합되는 분기 및 포크의 비율을 측정합니다. 하루 한번 이상 병합.
코드 변경을 승인하는 데 소요된 시간 확인. 코드 검토를 비동기식으로 수행하는 경우 변경 요청을 승인하는 데 걸리는 평균 시간을 측정하고 평균보다 더 오래 걸리는 요청에 주의합니다. 코드 검토를 개발의 일부로 수행하는 동기식 작업으로 만드는 방법 찾기.

다음 단계