우리는 Github를 이렇게 사용한다.

Seungwon Go
ReturnValues
Published in
6 min readFeb 1, 2018

개발팀마다 프로젝트/제품을 개발 시 사용하는 다양한 관리도구가 있겠지만, 우리팀은 Github 하나만을 이용해서 개발시 일어나는 모든 내용을 관리를 하고 있다. 그렇다면 프로젝트를 진행하면서 일어나는 크고 작은 이슈, 개발진행사항, 개발자간의 커뮤니케이션 등 다양한 task 들에 대해서 어떻게 Github 하나만을 이용해서 진행하고 있는지 소개하고자 한다.

이슈관리

프로젝트 진행시 나오는 모든 이슈, 고객 미팅, 개발 시 필요한 준비사항등 프로젝트에서 필요한 모든 내용을 우리는 이슈관리를 통해서 관리한다.

이슈관리에서 모든 내용을 관리하다 보니, Label을 체계적으로 만들 필요가 있었고, 현재 우리는 meeting, development, bug, todo, api, wbs 등으로 세분화 하여 모든 이슈는 그 이슈에 성격에 맞게 Label을 지정하여 사용하고 있다.

  • meeting : 고객/사용자와의 업무협의 미팅이 있는 경우 meeting으로 이슈를 등록하고, 해당 미팅시 필요한 내용/ 확인해야 할 사항/요청해야 할 사항 등을 미리 정리해 놓는다. 실제 미팅시 해당 이슈를 열어놓고 관련 정보를 기록하게 된다.
  • todo : 한주단위로 각자 해야 할 task을 등록한다. task 작성시 add a task list 버튼을 이용해서 task 목록을 작성하면, 이슈 리스트 화면에서 몇개의 task가 있고, 몇개의 task가 완료되었는지 직관적으로 확인할 수 있다.
  • development : 개발를 하기 위해서 사전에 완료되어야 하는 task 목록을 작성한다. 해당 task가 완료가 되어야 개발자가 실제 개발에 착수할 수 있다. 또한 개발시 주의해야 할 업무 내역과 비즈니스 로직을 정리하여 개발자가 개발시 참조하도록 한다.
  • bug : 개발자가 Projects 탭에서 개발목록을 개발완료로 이동키셔 놓으면 해당 개발목록에 대해서 테스트를 진행하고, 테스트에서 나온 bug 내용을 작성하게 된다.

Github의 Issues의 장점 중 하나는 Issue로 등록하고 해당 이슈에 코멘트가 달리면 아래와 같이 이메일로 모두에게 공유가 되는것이다.

Slack과 같은 별도의 채팅 도구를 사용하지 않더라도, 이메일을 통해 실시간 이슈 변경 사항이 공유가 되니, 아직까지는 크게 불편함 없이 사용하고 있다. 오히려 채팅도구를 이용해서 실시간으로 메시지가 계속 전달되고, 확인하고 답변해야 할 필요가 없어서 업무에 조금 더 집중할 수 있는것 같다.

개발진행관리

개발목록은 화면단위로 관리한다. 각 화면에 필요한 다양한 api 개발이 필요하더라도 이 각각을 별도로 관리하지 않고, 사용자가 직접 사용하는 화면단위로 목록을 관리한다. 개발 진행 현황은 Github에서 Projects 탭에서 Project을 생성하고, 개발목록/개발진행중/개발완료/테스트완료/최종개발완료 5개 컬럼으로 나누어서 관리 되어진다.

개발 주기는 한달 주기로 하며, 한달을 기준으로 개발해야할 목록을 개발목록 컬럼에 추가하며, 이때 개발해야 할 목록과 연관된 이슈 등록 번호를 맵핑해서 등록한다. 예를 들어 해당 화면 개발에 필요한 화면 정보 및 업무 정보/ DB 정보 등을 이슈에 상세등록하고 해당 이슈번호를 개발목록에 맵핑하여, 개발자가 쉽게 연관 정보를 찾아볼수 있도록 하고 있다.

개발자가 개발을 시작한면 해당 목록을 개발진행중 컬럼으로 이동시킨다.

개발이 완료되면 개발완료 컬럼으로 목록을 이동하고, 테스트 담당자는 개발완료 컬럼에 있는 화면에 대해서 테스트를 진행하게 된다. 테스트가 완료되면 Bug 목록을 이슈에 등록하고, 개발목록를 테스트완료 컬럼으로 이동시키고, bug가 작성된 이슈를 맵핑한다.

개발자는 테스트완료 컬럼에서 bug가 등록되어져 있는 개발목록은 다시 개발진행중 컬럼으로 이동시키고 bug를 수정하게 되고, 이 사이클을 bug가 없을때 까지 실행하게 된다.

모든 bug가 완료되면 최종개발완료 컬럼으로 개발목록이 이동되게 되고, 실 사용자의 UAT전까지는 최종개발완료 상태로 남게 된다.

개발코드 관리

이미 Github는 전세계 대다수의 개발자가 소그관리도구로 사용하는 범용적인 툴이 되었다. 우리팀 역시 Github을 이용해서 개발소스를 관리 하고 있다.

commit시 최대한 상세하게 commit내용을 등록하고 commit 카테고리를 지정하여 쉽게 찾고, 관리 될 수 있도록 하고 있다.

우리는 크게 아래와 같이 commit 카테고리를 관리하고 있다.

  • [INITIAL] — repository를 생성하고 최초에 파일을 업로드 할 때
  • [ADD] — 신규 파일 추가
  • [UPDATE] — 코드 변경이 일어날때
  • [REFACTOR] — 코드를 리팩토링 했을때
  • [FIX] — 잘못된 링크 정보 변경, 필요한 모듈 추가 및 삭제
  • [REMOVE] — 파일 제거
  • [STYLE] — 디자인 관련 변경사항

문서관리

마지막으로 각종 문서는 구글드라이브에서 관리하고 있고, 이슈 등록 시 아래과 같이 참조해야 할 문서에 대한 링크를 같이 등록하여 사용하고 있다.

현재까지는 Github 하나만을 가지고 프로젝트를 관리하는데 큰 어려움은 없고, 오히려 많은 효과를 보고 있는 것 같다. 그리고 조금 불편한 것들, 있으면 좋을것 같은 것들이 있는데.. 그런것은 Github 확장 app으로 개발해서 Github에 등록할 수 있을것으로 보인다.

사용자/고객 테스트 관

한가지 더 남아있는 과제는 우리는 실 사용자가 개발된 결과물을 테스트 하는 UAT기간에 각 화면에서 발생한 테스트 결과 내용 또한 Github에 이슈 기능을 통해서 받을려고 하고 있다.

이때 문제는 우리가 사용하고 있는 Github 레파지토리를 고객에게 공유를 해야 하는데, 이렇게되면 모든 이슈 항목등이 공개가 되서, 우리는 Github의 이슈 중 특정 Label을 같은 이슈만 따로 모아서 보여지고, 이슈 등록시 특정 label로 자동으로 등록되게끔 하는 별도의 화면을 개발하였다.

고객은 사용하는 화면이 전혀 Github인지 모르게 되고, 일반적인 이슈 관리 화면으로 생각하게 될것이다. 이렇게 까지 하고 나면, 초기 분석에서 설계, 구현, 테스트에 이르는 일련의 모든 과정을 Github을 이용해서 관리하는 전체 flow가 완성될것으로 보인다.

마치며

우리팀은 현재 Github을 이용해서 모든 프로젝트 내용을 관리하고 있고, 아직까지는 꽤 성공적으로 일을 해나가고 있다.

--

--