Dev Traveler

1. 개요

프로젝트를 진행시 CICD의 필수 구성요소로 VCS(Version Control System)을 많이 사용하는데 예전에는 SVN을 많이 사용하나 요즘 트렌드는 Git으로 점차 변경되고 있는듯하다.

Git은 분산 버전 관리 시스템으로 아래의 장점이 있다.

- 항상 중앙 Git서버와 통신하지 않으므로 속도가 빠름

- 예기치 못한 사고로 중앙관리 서버의 자료가 소실되었을 때 로컬에 자료가 있다면 복구할 수 있음

이런 Git도 장점만 있는것이 아니다. 단점으로는 

- CLI(Command Line Interface)에 익숙하지 않으면 생각보다 이해하기 쉽지 않음(단, source tree등의 툴을 사용하면 해결됨)

- 버전 충돌 문제 : 개발자가 많으면 많을수록 동일한 소스를 수정할 확률이 높아진다. 따라서 버전 충돌이 일어날 가능성이 다분하다. (이 문제도 항상 푸시나 커밋전  git pull을 통해 소스를 업데이트 받고 시작하면 문제가 안됨)

- 브랜치 구성 : 개발 인원에 따라서 브랜치를 어떻게 가져가냐가 중요하다. 이글을 쓰는 메인 주제이며, 스타트업의 경우는 복잡한 구성으로 갈 수 있으나 개발자의 역량(특히 SI 프로젝트)에 따라서 단순화한 브랜치 구성을 가야할 수 있다.

2. 브랜치 전략 종류

a. 3 브랜치

단순히 dev -> stage ->  prod 의 브랜치 구성으로 사용하는 전략이다.

개발자들은 dev 브랜치를 기존 SVN 쓰듯이 사용하며, 다른 stage나 prod 브랜치는 CICD 파이프라인을 통해서 통제한다.

해당 방식을 사용하는 이유는 고르지 않은 개발자들의 역량(일부 개발자들은 git을 모르는 경우도 있었음)및 대형 프로젝트 진행 시 통제를 용이하게 하기 위함이다.

b. 2브랜치

dev -> master 형태로 브랜치를 구성한다.

dev 브랜치는 push가 많으므로 따로 구성하고 master에서 stage 환경 및 prod(프로덕션 환경) 환경으로 배포한다. 이렇게 구성시 JNDI 및 기타 환경에 종속받는 설정은 외부로 모두 빼고 Runtime 시에 해당 설정을 보고 구동될 수 있도록 설정해야 한다.

c. 1브랜치

master 하나만 구성한다.

브랜치 1개를 통해서 관리하며, 위 2가지 방식보다 더 devops 스럽다. (무조건 환경설정을 외부로 빼야하기 때문) 단, 기존 1개의 브랜치를 여러 개발자가 SVN 사용하듯이 사용하는 것은 똑같기 때문에 브랜치 관리시 주의가 필요하다. 

d. gitflow

git역량이 뛰어난 개발 그룹  또는 소규모 스타트업에서 많이 사용하고 있으며, 본인이 원하는 기능을 개발시에 기존 브랜치에서 Feature 브랜치로 분리 개발해 이를 메인 브랜치에 합치는 전략이다.

충돌 해결 기법, 서로의 커뮤니케이션이 매우 중요하다.

3. 결론

프로젝트 진행 시 SI 프로젝트나 개발자가 git에 익숙치 않은 경우는 3브랜치 전략으로 가는 것이 맞다고 판단되며, 점차 Gitflow 방식으로 변화하는 방법을 선택해야 무리없는 프로젝트가 될 것이다.

(위 결론은 주관적인 생각이므로, 다르게 생각하셔도 무방합니다.)