Delivery Hero Korea는 요기요/배달통을 함께 서비스 중이다. 본 포스팅에서는 필자가 담당하고 있는 요기요 서비스의 GitHub Branch 운영 방법을 소개하려고 한다.
요기요 안드로이드 팀의 Git Branch는 아래와 같이 운영하고 있다.
Master : Release 완료한 버전을 merge 하고, Release 완료 시 Tag를 함께 둔다.
Developer Branch : Master Branch 기준으로 티켓 단위 개발 작업을 진행하며, 필요에 따라서 타 Developer Branch를 Merge 한다.
Release Branch : 릴리즈 플래닝이 끝나면 작업 완료한 티켓을 머지 한다.
HotFix Branch : HotFix가 필요한 경우 Release Branch와 같은 역할을 한다.
Code-Review Branch : Code Review 목적으로만 사용하는 Branch이며, 최신 코드가 항상 유지되며, 언제든 삭제 및 다시 생성될 수 있다.
티켓 처리 과정은?
일반적인 회사는 아래와 같이 Branch와 Release Planning을 운영하고 있다.
x.x.x에 나갈 릴리즈 플래닝을 계획한다.
x.x.x에 나갈 릴리즈 플래닝 중 기간 안에 작업 가능한 범위를 조율하고, 중요한 작업을 우선 선정한다.
릴리즈 일정에 맞게 작업한 내용을 Release Branch에 Merge 한다.
1~3단계가 안정적으로 끝나면 좋겠지만 실제론 이런 경우가 많다.
x.x.x에 나갈 릴리즈 플래닝을 계획한다.
x.x.x에 나갈 릴리즈 플래닝 중 기간 안에 작업 가능한 범위를 조율하고, 중요한 작업을 우선 선정한다. → 이거 꼭 나가야 해요. 추가해줘요. (중간에 일이 생긴다)
3. 릴리즈 일정에 맞게 작업한 내용을 Release Branch에 Merge 한다. → 완성도가 떨어져서 이번엔 못 나가겠네요. 빼주세요.
일정 중간에 새로운 일이 들어오거나, 계속적인 계획이 변경되는 게 보통이다. 아무래도 초반엔 저런 식으로 하는 게 맞겠지만, 이미 어느 정도 안정화되었다면 다음과 같은 접근 방법도 시도해볼 만 하다. 요기요에서는 아래와 같이 운영하고 있다.
Jira에 새로운 티켓들이 계속 추가된다.
우선순위는 팀장급에서 조율한다.
조율한 티켓을 기준으로 개발자들은 우선순위대로 개발을 진행한다. → 단순한 티켓도 있고, 범위가 큰 프로젝트도 있다.
작업한 티켓은 Code Review를 진행한다.
Code Review가 끝나면 QA에 전달한다. 티켓 생성자와 실제 QA 팀에서 각각 확인한다. (티켓 단위로)
릴리즈 플래닝은 2~3주에 1회 진행한다. → 릴리즈 플래닝 때는 개발이 끝난 티켓만을 가지고, 플래닝 계획을 세운다. 정말 급한 건 이때 추가하기도 한다.
Merge 작업을 진행하기 위한 Release Branch가 생성되고, QA에서 전체 확인을 진행한다. → 가볍게 개발자 테스트를 진행 후 QA 팀에 전달한다. → 티켓 단위 테스트 때와는 다르게 더 자세하게 살펴본다.
약 7단계로 현재 요기요 안드로이드 팀에서 플래닝을 하고 있다.
그래서?
처음 입사했을 때 릴리즈 한다고 안내만 받았을 뿐 실제로 개발자들은 새로운 티켓에 집중하고 있었다. 신기할 따름이다. 보통의 회사에서는 릴리즈 날까지도 개발을 하거나, QA 하느라 정신이 없다.
이유는 간단했다. 티켓 단위로 생성한 사람이 확인하고, 간단한 QA 진행을 사전에 해버린다는 장점 덕에 추후 Merge만 잘하면 대부분 큰 문제없이도 릴리즈가 끝난다는 것이다.
필자는 정말 새로운 접근 방법이라고 생각한다. 그동안 일정에 쫓겨 개발하는 것만 알았지 이렇게 여유롭게 개발은 개발대로 QA는 QA대로 티켓은 또 추가되고, 잡아서 작업하고 하는 게 가능한지 몰랐다.
뭐 애자일 방식대로라면 이 방법은 좋은 건 아니다. 딱히 일정 산정을 할 필요도 없다는 단점이 분명 존재한다. 그렇다고 일정을 전혀 산정하지 않는 건 아니다. 조금 여유롭게 일정이 잡힐 뿐…
티켓 생성
Jira를 이용해서 새로운 티켓은 계속 생성된다. QA 팀에서도 생성하고, 각 팀에서 필요한 티켓을 발행한다. 빠른 개발이 필요하면 그에 따라 Stand By 상태의 티켓이, 그렇지 않으면 Block 상태로 남아있다.
필요하면 끌어올려서 언제든 작업하고, 우선순위가 높은 작업을 선 작업한다.
티켓을 잡고 작업을 시작한다.
티켓을 잡아서 작업을 시작한다. 이때 Developer Branch가 생성되며, 필요에 따라 Master 외 기존 Developer Branch로부터 시작하기도 한다.
사전 작업이 영향도가 크면 당연히 Developer Branch을 머지하고 시작하는 게 맘 편하다.
다행히 대부분의 티켓은 영향도에 따라 내보낼 시점을 우리가 정할 수 있다는 점이다.
코드 리뷰
코드 리뷰는 당연히 티켓 작업이 완료되면 진행한다. Code Review 상태로 전환하고, GitHub Pull Request를 날리고 진행한다.
Code Review Branch는 언제나 최신 코드 상태를 유지해야 하며, 빠르게 끝나야 하지만, 아직 진행 중인 단계이다.
코드 리뷰 후
코드 리뷰가 끝나면 QA가 가능한 상태로 티켓을 전환한다. 티켓 단위 QA을 진행하기 때문에 여기에서 누락한 부분을 사전 점검한다.
추후에 한 번에 하는 게 아닌 티켓 단위로 모두 미리 확인한다.
릴리즈 플래닝
현재 릴리즈 플래닝은 2~3주에 1회 진행하고 있다. 이때 개발팀에서 꼭 내보내야 하거나, PO(Product Owner) 팀에서 내보내야 할 티켓들을 담게 된다.
가끔은 개발 중이거나, 진행 전인 티켓도 이때 포함되기도 하는데, 이 시간을 넘었을 경우에는 더 이상 추가하는 티켓은 없다.
그리고 개발팀에서는 Release Branch을 생성하고, 각자가 작업한 티켓 단위 작업을 Merge 하는 작업을 진행한다.
그리고 개발팀에서 1~2일간 내부 테스트를 진행하고, 누락 코드를 확인하는 작업을 진행한다.
그리고 QA 팀에서 전체 확인 과정을 거친다.
릴리즈 후
QA 팀에서 전체 확인을 하고, 오류가 크지 않다면 다음 릴리즈에 포함하도록 처리하고, 높은 경우 해당 릴리즈에 포함하여 작업을 진행할 수 있도록 한다.
QA 기간에는 당연히 릴리즈 나갈 작업이 우선이지만, 새로운 티켓을 잡아도 문제는 없다.
릴리즈가 끝나면 Master에 포함하여 실제 배포를 완료한다.
정리하면
위의 내용을 정리하면 아래와 같은 그림이 나오는데, 이쁘지는 않다.
Code Review는 중간중간 진행하기 때문에 아래 그림에 포함하지는 않았으며, Feature Branch들이 N 개 생성되게 된다.
릴리즈 플래닝이 작업이 끝난 티켓을 대상으로 하기 때문에 전체적인 일정이 촉박한 경우가 많지는 않다. 또한 티켓을 잡고, 개발 중에 변경되는 사항이 생겨도, 전체 릴리즈 플래닝에 영향이 적다. 진짜 급해서 이번에 나가야 하는 게 아니라면, 그 티켓에서 모든 개발이 완료하기 전에 Code Review로 넘어가지 않기 때문이다.
그러다 보니 좀 더 편하게 작업하는 게 가능하다. 다만 Merge 해야 할 양은 분명히 많다.
이런 게 가능하려면?
이런 플로우가 가능하려면 결국 릴리즈 플래닝을 바라보는 시각이 변해야 한다. 개발 초기라면 이런 방법이 의미 없다. 아무것도 없는데 어떻게 저런 플래닝이 가능하겠는가?
어느 정도 안정적인 궤도에 올랐을 때는 시도해볼 법한 방법이라고 생각된다. 요기요는 어느 정도 안정화 상태이기도 하고, 항상 급하게 나가야 할 일이 적기 때문이기도 하다.
모든 게 티켓 단위로 이루어지며, 개발 시작부터 종료까지 티켓을 통해 트래킹이 가능하다. 어느 정도의 시간이 걸렸는지에 대한 트래킹은 아직 하지는 않지만, 할 수 있다고 생각된다.
항상 안정적이게 접근할 필요는 없지만 상호 간에 부담감이 적은 건 분명하다.
이렇게 운영하면 장/단점은?
릴리즈 플래닝을 거치기 전에 Code Review를 거친다. 그래서 단점으로 Merge가 2회 생긴다. 똑같은 코드를 2번 Merge해야 하는데, 생각보다 양이 많을 경우도 있지만, 중간에 영향도가 큰 작업은 대부분 사전 Merge를 통해 이를 해결하고 있다. (이렇게라도 해야 나중에 작업할게 줄어들긴 한다)
필자의 경우는 약간 루즈하게 느껴질때도 있지만, 앱의 안정성을 생각해보면 충분한 시간이 필요하다고 생각된다. 딱히 급하게 처리할 필요 없다는 생각이 들어서 천천히 처리하기도 하지만, 정말 못해서 늦어지는 경우도 생긴다. 여하튼 필자는 전자의 경우가 간혹 생길 때도 있었다.
추후 릴리즈 플래닝이 꼭 나가야 할 티켓을 사전에 알고 있는 게 아니라서 부담감은 상대적으로 적다.
그리고 업무시간에 집중만 잘하면 티켓 처리하는 시간을 상대적으로 줄일 수 있다. (단점은 일정 산출을 잘 하지는 못한다는 것이다.)
장점은 업무시간 집중만 잘하면 정시 출/퇴근이 가능하다는 것이다. 야근하는 경우는 정말 좀 만 하면 끝날 것 같은 데에서 시작하는데 그 경우가 많지는 않았다. 보통 내가 좀만 더 하고 가야지 해서 야근하는 경우를 제외하면 야근하지 않는다가 필자의 원칙이다.
이 방법으로 작업하는 건 분명한 장/단점이 있지만 어느 정도 안정화되었다면 여러분도 도전해볼 수 있을 법 하다. 다만 위에서 이렇게 하는 걸 어느 정도 인정해줘야겠지만 말이다…
권태환, Android Developer @Delivery Hero Korea
*참고: 2018년 12월 RGP Korea 사명이 Delivery Hero Korea로 변경되었습니다.
→ About Delivery Hero Korea → About Delivery Hero
가입하기
