깃 기반에서 팀 프로젝트 운용이나 방법론을 개인적으로 정리하는 글입니다. #오해금지 #딴지금지 #지적환영
자동화된 테스트가 부족하고 우리 회사같이 금요일에는 배포가 없다든지 그리고 코드리뷰가 끝나길 기다려야 하는 등등 기다림이 있는 상황에는 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 되고 리얼에 배포된후 HotFix가 발생하면 master의 v1.0에서 시작되는 HotFix-blah 브랜치를 생성해서 수정을 반영한다. HotFix-blah는 master에 v1.0.1 버전으로 Tagging되어 머지되고 다시 develop에도 머지된다.
복잡하지만 아래 그림이 이 모든 것을 설명하고 있다.
QA가 있기도 하는 등 익숙해 보이는 방식이기도 하지만, 개발자가 시작 브랜치를 판단하거나 QA 또는 Product Manage 팀에서 Ticket 별로 시작 브랜치를 알려줘야 하거나 특히, HotFix가 머지 될 때는 신경이 쓰이는 부분이 있다. 아무래도 단계별 진행과 버전 Tagging이 있어 버전으로 릴리즈하는 소프트웨어는 유리하지만 Continuous Deployment에는 적합하지 않다.
참고
자동화된 테스트가 부족하고 우리 회사같이 금요일에는 배포가 없다든지 그리고 코드리뷰가 끝나길 기다려야 하는 등등 기다림이 있는 상황에는 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 되고 리얼에 배포된후 HotFix가 발생하면 master의 v1.0에서 시작되는 HotFix-blah 브랜치를 생성해서 수정을 반영한다. HotFix-blah는 master에 v1.0.1 버전으로 Tagging되어 머지되고 다시 develop에도 머지된다.
복잡하지만 아래 그림이 이 모든 것을 설명하고 있다.
QA가 있기도 하는 등 익숙해 보이는 방식이기도 하지만, 개발자가 시작 브랜치를 판단하거나 QA 또는 Product Manage 팀에서 Ticket 별로 시작 브랜치를 알려줘야 하거나 특히, HotFix가 머지 될 때는 신경이 쓰이는 부분이 있다. 아무래도 단계별 진행과 버전 Tagging이 있어 버전으로 릴리즈하는 소프트웨어는 유리하지만 Continuous Deployment에는 적합하지 않다.
참고
댓글
댓글 쓰기