Git Branch - 릴리즈 플래닝 - 회사에서 하고 있는 걸 정리해본다.
개인 광고 영역
다니고 있는 회사에서 사용하는 Git branch 관리하는 방법을 정리하려고 한다. 회사 블로그에 작성하는 글이 아니므로, 완전하지는 않지만 대략적인 내용을 정리하려고 한다.
RGP Korea 블로그에서 자세한 내용 확인 가능 - 요기요 Android 개발 Git Branch와 Release Planning
회사에서는 아래와 같이 브런치를 가지고 있다.
Master: Release 완료한 버전을 merge 하고, Release 시 Tag를 함께 둔다.Developer Branch: Master Branch 기준으로 티켓 단위 개발 작업을 진행한다.Code-Review Branch: 이 Branch는 언제든 제거하고, 다시 생성될 수 있으며, Code review 목적으로 둔다.Release Branch: 릴리즈 플래닝이 끝나면 작업 완료한 티켓을 머지 한다.
여기서 중요한 부분은 Release Branch는 릴리즈 플래닝을 거친 다음 생성하게 된다. 보통 Release 플랜을 하고, 만들어지는 건 같지만, 사전 작업된 티켓들을 기준으로 한다는 점이 기존 Release branch와 다르게 운영되고 있다.
보통 아래와 같이 Branch 운영하는 게 일반적이다.
- 이번 릴리즈에 포함할 내용을 사전 정의한다.
- 개발 일정을 산정하고, 개발을 진행한다.
- 릴리즈 일정에 맞게 작업하기로 한 내용을 release branch에 merge 한다.
1~3 단계가 모두 안정적으로 진행되면, 릴리즈에 문제가 없다.
현실적으로 접근하면 1번 단계를 거치더라도, 중간에 이건 꼭 필요해!라는 부분 때문에 언제든 작업량이 늘어나고, 처음 생각한 개발 일정보다 느려지는 경우도 많아진다. 또한 디자인 변경 요소도 생각해야 한다. 이런 모든 부분을 사전에 파악할 수 있다면 정말 좋겠지만 그렇지 못하다. 그래서 야근이 생기고, 야근을 해가면서 작업하더라도, 이거 제외하자!라는 말이 나올 때도 있다. 결국 rebase을 하거나, 다시 Merge 하거나, 이미 영향성 가진 branch의 시작점이 기존과 다르게 영향을 미칠 때도 있다. 그러면 관련 작업을 함께 내보내기 위해서 결국 일정이 밀리는 경우도 있다.
이게 그간 겪었던 문제들이다. 처음 산정한 릴리즈 플래닝을 완벽하게 하려면, 기획도 잘 나와야 하고, 개발/디자인 일정도 잘 정해야 한다. 또한 누군가의 중간 개입이 있어서는 안된다.
하지만 좋은 게 좋은 거니깐… 추가할 수밖에 없다.
이 글은 지금 다니고 있는 회사에서 나름 잘 돌아가고 있는 부분을 정리하는 글이며, 추후 회사 블로그를 통해 다시 한번 작성할 예정이다.
티켓 생성
회사에서는 티켓을 생성하고, 그에 따라 작업을 할당하거나, 직접 할당한다. 모든 작업은 티켓을 베이스로 진행하며, 이 티켓은 필요한 부서에서 각각 생성한다.
내가 속한 팀에서는 우선순위를 팀장님이 정하고, 작업을 순서대로 가져간다. 약간의 칸반 형태라서 꼭 순서대로 할 필요는 없지만 가능한 한 빨리 해결해야 할 작업을 우선 처리한다.
티켓을 잡고 작업을 시작한다.
티켓을 잡고 작업을 시작한다. 이때 Developer Branch를 생성하게 된다. 이때 Master을 기준으로 Branch을 생성하게 되며, 필요에 따라 사전 작업에서 미리 가져오기도 한다.
당연히 영향도를 생각하고, 이번 버전에 나갈지 말지를 대략적으로 파악해야 한다. 코드 베이스가 변경되었다면 당연히 그 티켓은 사전 머지 하는 게 필요하다.
코드 리뷰
코드 리뷰는 티켓 작업이 끝나면 진행한다. 코드 리뷰는 팀원 분들과 함께 진행하며, GitHub Pull request을 기준으로 확인한다. Code Review 브런치는 플래닝 미팅이 없기 때문에 별도로 운영하며, 항상 최신 코드를 기준으로 확인한다.
코드 리뷰 후
코드 리뷰 후 티켓 단위 QA가 진행된다. 티켓 단위 QA을 하기 때문에 확인 작업이 크지는 않다. 추후 Release 플래닝을 거친 후 전체 Merge 후 전체 QA 일정이 또 있다.
티켓 단위로 사전 확인이 이루어지기 때문에 개발에서 나올 오류들은 미리 파악하기 쉽다.
릴리즈 플래닝
코드 리뷰가 끝나고 티켓 QA 진행 중인 부분부터 릴리즈에 포함된다.
보통은 릴리즈 플래닝이니깐 말 그대로 플래닝을 해야 한다. 이번 버전에 어떤 작업을 해야 할지를 정하는데, 여기서 다른 점은 티켓은 티켓대로 처리되며, 플래닝은 별도라고 생각하면 되겠다.
상대적으로 릴리즈 자체에 부담감이 적고, 티켓을 빠르게 처리하는 게 가능하다. 릴리즈때의 부담감은 오직 Merge 작업 중 누락 코드가 생기지 않도록 하는 부분이 중요하다.
정리하면
위의 내용을 정리하면 아래와 같은 그림이 나온다. 원래 생각하는 그림보다 훨씬 이쁘지는 않다. 그래서 Code Review에 대한 부분은 그림에서 제외했다.
문제는 모두 Master에서 불러다 쓰다 보니, 이쁘지는 않다. 그림으론 이쁘지 않지만, 실제 작업에 대한 부담감은 훨씬 적다.
이런 게 가능하려면?
결국 이렇게 하려면 릴리즈 플래닝을 바라보는 시각이 변해야 한다. 근데 애자일 이론에는 맞지 않을 것이다. 계획을 세우고 들어가야 하니깐 이 방법은 나에게도 생소한 접근 방법이었다. 처음 입사했을 때 여긴 릴리즈 언제 하는지도 크게 신경 쓰지 않고, QA가 책임지고 릴리즈하고 있었다.
생소한 분위기였다. 보통의 회사는 릴리즈가 다가오면 개발자부터 다 바쁘다. 다른 작업할 시간이 없다. 오죽하면 야근까지 해가면서 일정에 맞추려고 하겠는가?(생각해보면 다른 작업하는 것도 이상하다)
정시 출근 정시 퇴근이 가능한 정도다 어떻게 보면 천천히 돌아가는 것 같지만 업무시간에만 집중해도 릴리즈에 문제가 없고, 오히려 릴리즈에 대한 부담감이 적다.
이슈 트래킹을 통해 오류 나는 부분을 확인하고, 다음 릴리즈에 반영하거나, HotFix 진행하면 된다.
생소했지만 새로운 접근 방법에 신기할 따름이다. 여길 벗어나면 보통의 방법으로 접근하거나, 애자일에 맞게 작업하는 걸 터득하게 될 것 같다.
이렇게 운영하면 장/단점은?
Release 플래닝의 뜻은 동일하다, 다만 작업이 끝난 티켓이 있느냐 없느냐의 차이가 있다. 릴리즈를 정하고 작업량을 개발자가 산정하는 게 보통 불가능하다. 그만큼 수많은 학습이 필요하다는 장/단점이 있다. 사실 나도 작업하기 전까진 이게 얼마나 큰 작업인지/작은 작업인지 파악하기 쉽지 않다.
크다고 생각하고 들어갔는데 1줄만 수정할 때도 있고, 파악 못해서 몇 시간 걸리는 일도 많다. 하지만 티켓 단위 처리라서 이러한 부담감은 훨씬 적다. Code Review만 잘 정착한다면 오히려 더 좋은 방법일 것 같다.
또한 추후 Merge 하는 방법이다 보니, Rebase 할 부담감이 적다.
하지만 Code Review와 Release Branch에서 머지 해야 할 부분이 2번이고, 코드 리뷰도 전체 2번 거쳐야 한다. 모든 티켓이 언제 나갈지 사실 모르고 작업을 진행한다.(중요한 티켓이야 일정이 있지만)
그 대신 릴리즈 플래닝 때 잘 이야기해서 풀어나갈 수 있다.
완전히 이쁜 그림이 나오지는 않지만 현재 상태가 나는 나름대로 마음에 든다.
마무리
이 글은 추후 회사 블로그가 만들어지면 좀 더 자세하게 정리하게 될 것이다. 현재는 개인 블로그에 올리기 위해서 짧게 정리해보았다.
아무리 개발을 잘하더라도, 개발 일정을 산정하는 건 쉽지 않다. 중간에 치고 들어오는 일도 처리해야 한다.(완전한 애자일 이론을 따르는 경우라면 중간에 치고 들어오는 일은 있을 수 없겠지만) 그런 것들을 생각해보면 상대적으로 쉽게 개발을 진행하고 있다는 생각이다.
그래도 꼭 배포해야 할 건 우선순위가 있으니 먼저 개발하는 건 당연하다.
Comments