EMD Blog

Github를 통한 이슈관리 본문

Git

Github를 통한 이슈관리

EmaDam 2021. 5. 21. 13:24

이슈관리

 현재 사내에서는 원격 Git repository로 Github를 채택해서 사용하고 있다. 현재 구성원은 백엔드 개발 2명 프론트개발 1명이 맡아서 하고 있고 각 개발자들은 자신들이 맡은 영역을 개발하고 있으며 겹치는 부분이 있지는 않아 협업으로서의 Git사용을 하고 있지는 않다. 그래서 Git을 코드 관리 측면에서만 계속 사용하고 있었고 간단하게 Branch 관리만 하면서 작업을 진행하고 있었다. 하지만 개발이 진행됨에 따라 출시 이후 버전 관리라던가 개발 및 배포 프로세스를 어떻게 잡을 것인지 주기는 어떻게 할 것인지 등 다양한 문제를 생각하지 않을 수 없게 되었다. 사실 개발을 시작했을 때부터 고민하고 잡고 갔어야했을 문제였지만 사정이 여의치 않다는 핑계를 대면서 미뤄왔었고 이제 간단하게 나마 사내 Github을 통한 이슈관리의 표준을 잡게 되었다. 

 

기존의 문제

 기존에는 master(혹은 main) branch에서 develop branch를 생성하고 그 밑에 하위 작업별 하위 branch를 작성하는 것은 각자의 자유에 맡겼으며 Commit 주기나 메세지 작성에만 신경을 쓰고 있는 상황이였다. 사실 협업이라고 할 것이 없었기 때문에 이러한 방식의 관리는 각자의 스타일에 맞게 편하게 관리하고 빨리 개발하자라는 의도가 많았고 Git의 사용 결과도 그저 코드를 history와 함께 저장해놓은 것에 지나지 않았다. 하지만 우리는 다같이 개발 공부를 하는 것이 아닌 실제 서비스를 출시하려는 것이기 때문에 이번 버전에서 어떤 기능이 추가 되었고 또는 어떤 버그가 수정되었는지에 대한 정보를 공유할 필요가 있었다. 그것은 이 서비스를 사용하려하는 사용자에게나 같은 팀 내의 다른 개발자에게도 유의미한 정보이기도 하다. 매번 개발이 끝나고 새로운 버전이 배포될때마다 다른 개발자에게 가서 '아 이번에는 이런 기능이 추가 됐어 ^^' 이렇게 말할 수는 없는 것이다. 그리고 이렇게 개발을 하다보면 자기 자신도 어떤 기능을 개발했고 어떤 버그를 수정했는지 잘 기억하지 못할때가 있기도 하다. 

 

개선방법

 Github내에 Issue를 관리할 수 있는 방법이 있다는 것을 확인했다. 사실 이런 식의 관리가 가능하다는 것을 알고 개선을 시작했다. Github에는 각 작업을 관리할 수 있도록 issue관리를 제공하고 있다. issue란 모든 작업이다. 기능에 대한 추가일 수도 있고 무언가를 수정해야하는 일 일수도 있다. 그런 것들을 자신이나 다른 사람들이 issue에 남기면 개발자들은 issue를 보고 개발을 명확하게 진행할 수 있게되는 것이다. 특히 이 issue는 단순히 기록만 하는 것이 아닌 내부 시스템과의 연동이 굉장히 잘되어 있기 때문에 Pull request에 특정 단어와 이슈 번호를 적어 놓는 것만으로도 이슈를 종료 시킬 수 있으며 특정 IDE에 연동해서 task관리를 할 수도 있다. 

 

 위 도식표는 우리가 사용하고 있는 Github issue를 통한 개발 프로세스다. 먼저 출시할 버전을 milestone으로 정의한다. 그 후 해당 버전안에 포함될 추가 기능이나 버그 수정사항 등을 issue로 생성해서 milestone으로 묶는다. 그 후에 develop 브랜치 하위에 issue에 맞는 브랜치를 생성해서 작업을 진행하고 작업이 끝난 issue는 develop branch에 PR을 보내 jenkins에서 테스트 후 성공하면 코드 확인 후 Squash commit한다. 이후 개발환경에서 테스트 후 문제가 없으면 master에 같은 방법으로 PR 후 rebase나 commit을 진행한다. 이렇게 반복 진행하다가. 해당 버전의 issue가 전부 close되면 버전을 tag한다. 

 

위 방법의 문제점

 이런 관리 방법에는 정답이 존재하지 않고 다른 개발 팀원들이 거부감 없이 사용할 수 있어야하기 때문에 최대한 간단하면서도 명확하게 했다. 하지만 master에 commit될때도 ECR에 Push가 되도록 설정되어있는데 그러면 버전이 release되기전에 기능별로 배포가 되므로 원래의 의도에 어긋나게 된다. 이 부분에 대한 다른 방법을 찾을 필요가 있을 것 같다. 

 

'Git' 카테고리의 다른 글

Github Team 별 액세스 권한 설정  (0) 2022.09.04