Mainline Branch Development

깃 기반에서 팀 프로젝트 운용이나 방법론을 개인적으로 정리하는 글입니다. #오해금지 #딴지금지 #지적환영

메인라인 브랜치 모델은 브랜치 전략중 가장 쉬운 방법이다. 작업 하는 브랜치가 몇개 안되기 때문인데,, 개발자들은 하나의 중앙 브랜치에 계속 커밋을 한다. ( 이를테면 마스터 브랜치? ) 문제는 항상 배포준비가 된 상태의 브랜치를 유지해야 하는 어려움이 있다. 정확히는 마스터 브랜치 하나만 두고 개발을 하는 방식이라 개발자는 로컬 브랜치나 "git stash"를 사용해 리뷰나 빌드에 대응하게 된다.

그리고 이 모델은 프로젝트가 커지고 개발자별로 또는 스프린트별로 브랜치 많아 지면 머지비용이 커진다. 가령 개발자들이 각자 자신의 브랜치에서 작업하다가 각자 개발을 마치고 다른 사람 개발 내용을 합친다고 생각하면 쉽다. 코드충돌이 없으면 쉽지 않나? 라고 생각 할 수 있지만, 코드충돌이 없다 하더라도 사용하는 라이브러리가 변경되었거나 이기종 플랫폼간 메세지 통신을 할 때 메세지 포멧이 바뀐 상황이라면 머지비용은 적지 않다.

그래서 이 Mainline Model은 Continuous Integration 과 Continuous Delivery 패러다임에 적합한 모델이다. 그리고 개발에 대한 규칙이나 규범이 아주 잘 정비되고 개발자들이 잘 훈련되었다면 큰팀으로 확장 하기가 쉽다 - 잘 정비된 프로세스와 잘 훈련된의 뜻을 좀더 정리해 보면 - 예를들어서, 새로운 기능이 추가되는데 이 기능은 구현에 시간도 오래 걸리고 영향범위도 넓은 기능이라고 가정해 보자. 이 "기능을 잘게 쪼개고 작은 커밋으로 추가할 수 있는 프로세스가 있고 이 프로세스위에서 개발 할 수 있는 개발자들" 이라는 뜻이 되겠다.

그리고 Feature Toggle을 이용해 완료되지 않은 작업은 설정으로 제어할 수 있어야 한다.

결과적으로, 항상 배포준비가된 코드를 유지한다는 점 그리고 Feature Toggle 이 사용된다는 점을 고려해야 한다. ( Feature Toggle은 많은 곳에서 사용하지만 위험성?도 고려되어야 한다는 뜻이다. )


Feature Toggle에 관한 링크 

http://martinfowler.com/bliki/FeatureToggle.html
http://abhishek-tiwari.com/post/decoupling-deployment-and-release-feature-toggles
http://code.flickr.net/2009/12/02/flipping-out/
http://www.mentalexertion.com/blog/2014/03/08/qcon-london-2014-continuous-deployment-at-etsy/
http://fernandorubbo.blogspot.kr/2013/03/feature-toggles-good-or-bad.html