기본 콘텐츠로 건너뛰기

11월, 2015의 게시물 표시

GitFlow

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

자동화된 테스트가 부족하고 우리 회사같이 금요일에는 배포가 없다든지 그리고 코드리뷰가 끝나길 기다려야 하는 등등 기다림이 있는 상황에는 Ticket 별로 Feature 브랜치를 생성해서 개발하는 GitFlow 브랜치 모델이 적합하다.

프로젝트 시작은 develop 브랜치에서 하고 Feature가 추가 될 때 Ticket (이슈) 별로 Feature 브랜치를 생성하고 Integration 브랜치를 두어 Feature를 머지하는 방식은 다른 브랜치 모델과 유사하다. 물론 Feature 브랜치가 시작되는 브랜치가 develop 인 것도 같다.

버그를 수정할 때, Waterfall 방식으로 개발하는 팀에서는 기간을 정해 QA 주관하에 진행 버그를 수정하게 되고, 애자일 방식을 가진 팀은 개발자가 Ticket 별로 여러 브랜치를 생성/개발을 하고 테스트는 다른 사람들이 진행한다. 그리고 두 가지 개발방식 모두 release-1.0과 같은 Integration 브랜치를 생성하고 QA를 한다. 어떻게 보면 당연하지만, Release 브랜치에는 Feature Freeze - https://en.wikipedia.org/wiki/Freeze_(software_engineering) 라는 개념이 필요하다. 즉 Release 브랜치에는 버그 수정은 하되 더는 기능추가를 하지는 않는다.

그리고 Feature Freezing 중 버그는 Release 브랜치에 적용되고 다시 develop에도 머지된다. 이렇게 Release 브랜치에서 QA를 계속 진행하며 모든 버그가 수정되면 배포준비 생태의 Release 브랜치가 하나 완성된다. 일반적으로 QA가 끝나고 Sign Off가 된 상태를 말한다. 그러면 master에 v1.0과 같은 버전을 하나 Tagging 하고 배포를 한다.

이렇게 끝나면 좋은데 보통 리얼에 배포되면 HotFix가 생기게 마련이다. 버전이 Tagging 되…

Branch Per Feature

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

Branch Per Feature는 브랜치 하나로 쓰는 전략은 아무래도 제약이 많아서 Feature 브랜치와 Integration 브랜치를 활용하는 방법에 대한 내용이다. Feature 브랜치와 Integration 브랜치는 하는 일은 같은데, 단지 어떤 커밋들을 대상으로 하느냐의 차이가 있다.

모든 작업은 Feature 브랜치에서 이루어지고 Integration 브랜치를 통해 다른 개발자 커밋을 반영하는 등 최신상태를 맞춘다. 릴리즈 할 때는 Integration 브랜치를 생성하고 빌드에 포함할 Feature만 골라 머지하고 릴리즈를 한다. 즉 마지막 빌드이후 완료된 모든 작업을 포함할 필요가 없다.

이렇게 Feature 브랜치와 Integration 브랜치를 활용하면 특정 코드가 배포되는 것을 막을 수도 있고 배포가 준비된 상태를 유지 할 수도 있다.

이런 Feature별 브랜치 모델에 대해 좀 더 자세한 내용은 ( http://dymitruk.com/blog/2012/02/05/branch-per-feature ) 링크에 설명되어있고, 조금 더 초기 모델이 GitHub Flow 다. ( http://scottchacon.com/2011/08/31/github-flow.html )

GitHub Flow 브랜치 모델에서 master는 항상 배포가능한 브랜치다. 개발자는 Feature 브랜치를 만들고 개발하고 master 브랜치에서 코드를 가져와 최신상태를 유지한다. 작업이 완료되거나 다른 개발자와 협업 또는 도움이 필요하면 Pull Request를 master 브랜치로 날리고 이슈트래커에서 개발한 기능에 관해 이야기를 나눈다.

이런 GitHub Flow와 Dymitruk 모델과 차이점은 단지 어떻게 배포가 일어나는가의 차이다. 즉 Dymitruk 모델은 어떤 Feature를 선택해서 빌드하느냐이고, GitHub Flow는 Pull Request가 수락되면…

Mainline Branch Development

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

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

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

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

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

결과적으로, 항상 배포준비가된 코드를 유지한다는 점 그리고 Feature Toggle 이 사용된다는 점을 고려해야 한다. ( Feature Tog…