CI/CD를 위한 브랜치 전략

DVCS의 브랜치

분산식 버전 관리 시스템(DVCS), 특히 브랜치 작업을 간소화한 Git의 인기가 높아짐에 따라 개발 팀에서 브랜치 전략을 고려하게 되었습니다.

분산식 시스템의 경우 저장소 사본이 여러 개 있으므로 소스 저장소도 여러 개입니다(물론 일반적으로 팀에서 중앙 또는 기본 사본 지정합니다). 팀은 저장소 사본의 변경 사항을 동시에 수정하고, 동일한 저장소의 다른 사본에 변경 사항을 푸시하여 작업을 공유할 수 있습니다.

Git을 통해 브랜치 생성 및 다른 브랜치의 커밋 병합 작업이 매우 간단해졌습니다. Git에서 브랜치는 특정한 이름으로 라벨이 지정된 커밋(또는 커밋 집합)입니다. 브랜치는 새로운 기능을 만들거나 해킹 실험을 수행하는 등 일련의 변경 사항을 제어하는 데 적합합니다.

또한 브랜치를 다른 저장소에 푸시하거나 마스터 브랜치 등의 다른 브랜치에 병합하여 코드베이스의 나머지 부분과 연결함으로써 변경 사항을 공유할 수도 있습니다. 변경 사항을 사용하지 않기로 한 경우엔 변경 내용을 삭제할 수도 있습니다. 브랜치 두 개를 병합할 때 Git은 각 브랜치에 대한 커밋 정렬을 처리합니다. 또한 다른 버전 관리 시스템의 병합과 관련한 복잡성도 감소합니다.

피처 브랜치

이름에서 짐작할 수 있듯 피처 브랜치는 개별 기능을 코드베이스의 나머지 부분과 구분하여 별도로 유지하기 위해 생성됩니다. 마스터 브랜치와 진행 중인 작업을 별도로 유지하면, 릴리스 브랜치(하단 참조)가 아닌 마스터에서 직접 배포하는 경우 한층 쉽게 마스터를 배포 가능한 상태로 유지할 수 있어 미완성 기능이 프로덕션 단계로 배포될 가능성이 감소합니다. 브랜치를 중앙 저장소(지정된 경우) 또는 다른 저장소로 푸시하여 팀원들과 작업을 계속 공유할 수 있습니다.

피처 브랜치의 가장 큰 단점이자 트렁크 기반 개발을 선호하는 분들이 자주 비판하는 점은 기능이 ‘완성’될 때까지 변경 사항의 통합이 지연되므로 지속적 통합의 이점을 누릴 수 없다는 점입니다. 이로 인해 병합 충돌의 위험이 발생하고, 변경 사항이 반복적으로 커밋된 경우 수정하는 데 오랜 시간이 소요되는 복잡한 버그가 발생합니다.

피처 브랜치와 마스터(또는 릴리스를 준비하는 데 사용되는 브랜치)에서 자동화된 빌드 및 테스트를 실행하도록 CI 서버를 설정하면 이러한 문제를 줄일 수 있습니다. 이를 통해 빌드 중인 항목에 대한 즉각적 피드백을 받고, 변경 사항 병합 시 발생하는 문제의 위험도 줄일 수 있습니다.

병합 충돌을 최소화하는 한 가지 방법은 피처 브랜치의 수명을 최대 하루나 이틀 정도로 짧게 구성하는 것입니다. 또 다른 옵션은 브랜치를 정기적으로 마스터의 변경 사항에 리베이스 또는 병합하는 것입니다. 이를 통해 마스터에 커밋된 다른 모든 변경 사항을 피처 브랜치에 업데이트할 수 있습니다. 하지만 동시 작업이 가능한 대다수의 피처 브랜치가 모두 마스터 커밋을 지연시키는 경우 충돌 위험이 제거되지는 않습니다.

핫픽스 브랜치

핫픽스 브랜치의 작동 원리는 피처 브랜치와 유사하지만 모든 방식을 소개하기 위해 살펴볼 가치가 있습니다. 핫픽스 브랜치는 버그 수정 사항을 프로덕션에 최대한 빠르게 제공하는 것을 목표로 합니다.

배포 위치에 따라 마스터 또는 릴리스 브랜치에서 핫픽스 브랜치를 생성할 수 있습니다. 피처 브랜치와 마찬가지로 릴리스 또는 마스터 브랜치에 병합하기 전 핫픽스 브랜치에서 일부 CI/CD 요소를 실행하도록 선택할 수 있습니다. 따라서 릴리스에 앞서 자동화된 테스트를 추가로 수행할 수 있습니다.