[Git] 프로젝트의 Git brunch 관리 정책

728x90

개요

프로젝트를 진행하다 보면, 그리고 버전관리 툴을 git 을 사용 중에 있다면 한번쯤은 brunch 정책에 관련해서 팀원들과 논의 해본적이 있을것입니다.

저희팀도 각 상황에 맞게 brunch를 관리 하기 위한 팀원들간의 정책을 논의하였고, 최대한 해당 규칙에 어긋나기 않게 하기 위해서 노력중입니다.

이미 많은 분들은 각 프로젝트에 맞는 brunch 정책을 가지고 계실것으로 보이며, 그렇지 않은 분들에게는 도움이 되고자 간략하게 정리해 보았습니다.

모든 정책에는 결국 의지가 중요하죠.

master 브런치의 역활은?

저희는 master 브런치는 빌드가 가능한 최상의 상태를 항상 유지해야 한다는 정의를 세웠습니다.

언제든 현재 시점으로 빌드 및 배포가 가능한 상태여야 하고, 각 상황에 맞는 Tag 및 브런치로 바로 전환이 가능한 상태를 유지하는 것을 팀원들간의 정책으로 결정했다.

우리 프로젝트의 릴리즈 단계를 확인한다.

개발단계 (dev)

실질적인 개발이 이루어 지는 단계로, 가장 기본적인 작업 브런치이다.

내부QA 단계 (dev_qa)

개발과정에서 정해진 완료 시점을 기준으로 생성되는 브런치 이며, 내부 QA를 진행하기 위한 브런치이다.

퍼블리셔 QA 단계 (publisher_qa)

내부 QA 단계가 통과가 되면 퍼블리셔 QA 를 진행하게 된다. 이때 생성하는 브런치이다.

준비단계 (staging)

모든 QA가 완료 된 이후, 배포전 준비단계의 brunch이며, release 상태에서 hotfix 발생시 QA를 대체 할 수 도 있는 단계이다.

릴리즈단계 (release)

실제 서비스가 될 brunch 로서, 퍼블리셔 QA 단계가 완료 된 시점에 staging과 release 브런치가 생성된다.

긴급수정단계 (hotfix_00)

라이브 서비스시, 발생하는 긴급 패치를 관리하기 위한 brunch 이며, 완료후 테스트는 staging 브런치에서 진행한다.

관리 Flow

1. master 브런치는 빌드가 가능한 최상의 상태를 항상 유지한다.

2. 모든 개발은 dev 브런치를 기본으로 작업한다.

3. 정해진 빌드 완료 시점 및 QA 완료 시점에 master 브런치에 Merge Request 한다.

4. master 브런치에 병합되는 단계에서 항상 정해진 규칙의 Tag를 생성 한다.

5. master에 병합이 정상적으로 진행 된 이후에 각 단계에 맞는 brunch를 생성한다.

Tag 의 사용을 권장할 것인가

팀원들간의 이해도가 조금씩은 달랐던 부분이지만, master 브런치에서 빠르게 태세전환을 하기 위해서는 꼭 필요한 것이 TAG 이다. 특히 여러개의 brunch를 생성해서 관리하는 정책이라면, 완료시점의 TAG는 꼭 필수로 진행 하여야 하며,

TAG의 네이밍 정책 또한 팀원들간의 공유가 필요하다.

릴리즈 이후 수정에 대한 대책은 어떻게 할 것인가?

릴리즈 이후 수정에 대한 이슈는 항상 존재한다. 완벽한 QA 단계를 거친다고 하여도, 항상 위험은 존재한다.

그렇다면 릴리즈 이후에도 위 단계를 따라가며 브런치 정책을 따를 것인가?

이는 위험 부담이 크다. 그렇기에 릴리즈 단계에서 발생하는 긴급 수정 사항에 대해서는

(다음빌드가 아닌, 바로 수정이 되어야 한다는 기준이다)

hotfix 브런치를 별도로 생성해서 수정하는 방안으로 정책을 결정하였고,

해당 브런치는 staging 브런치를 기준으로 테스트 후 릴리즈 상태로 변경하는 정책을 취한다.