도입 이유
처음 프로젝트를 했을 때는 다른 많은 팀원들이 있었고 각자 task 분배나 일정 관리 절차는 notion을 이용하였다. notion도 프로젝트 관리에 필요한 board와 같은 기능을 갖추고 있기 때문에 이를 활용하여 프로젝트를 진행할 수 있었다. 하지만 작업을 완료했음에도 불구하고 notion 내의 issue에 완료 처리를 제때 해놓지 않아 결국 notion에 있는 작업 현황 전체의 신뢰도가 떨어지는 문제가 있었다.
이번 프로젝트에서도 이런 문제를 겪지 않기 위해 automation을 어떻게 하면 할 수 있을까 고민하게 되었고 Github 내에서 issue tracking을 할 수 있는 도구가 있다는 사실을 알게 되었다. Github 내에서 프로젝트를 관리하게 되면 Pull Request와 Review, Merge 여부에 따라 자동으로 issue들을 관리할 수 있게 되므로 번거로운 절차를 거치지 않아도 되기 때문에 이 방법을 사용하기로 하였다.
한 일
Issue Template을 생성하고 이를 기반으로 새로운 Issue를 발행하는 작업과 Project를 새로 파고 이를 repository와 연결하는 작업은 별로 어렵지 않았다. 중요한 것은 이 Issue가 실제 개발 작업과 연관되도록 하는 것이었다. 찾아본 결과 다행히 Issue 기반으로 branch를 파는 기능이 이미 있어서 이걸 이용하면 될 것 같았다. 기본 branch 이름은 (issue 번호)-(issue 제목)으로 설정되어 있는데 개발자가 둘 뿐이므로 앞에 이름만 추가적으로 붙여서 branch 이름을 생성하기로 하였다.
그리고 Issue와 Pull Request는 다섯 가지로 나누어 관리하려고 하였다. 해야 할 issue를 모아 놓는 Todo, 일이 할당되고 진행 중인 일을 표시하는 In Progress, Pull Request가 등록되어 approve가 필요한 상태인 Review Requested, Approved된 Pull Request가 위치하는 Review done, 마지막으로 완료된 일들을 모아 놓는 Done으로 나누어 보았다.
내가 Github issue를 사용하면서 의도하였던 것은 다음과 같다.
- 새로운 issue가 등록되면 자동으로 EduMax 프로젝트의
Todo에 등록 - Pull Request 등록 시 자동으로 해당 Issue가
Review Requested로 이동 - 현재는Todo로 이동함. - Review 완료되어 approved되었다면
Review done으로 이동, 만약 고칠 점이 필요하면 다시In Progress로 옮긴다. - Pull Request가 merge되었다면 최종적으로 해당 Pull Request를
done으로 이동 - issue가 close되면 자동으로 해당 issue를
done으로 이동
약간 아쉬운 것은 issue와 이에 관련된 Pull Request가 같이 움직였으면 좋겠는데 이대로라면 issue와 Pull Request가 독립되어 움직이는 것처럼 보일 것 같다는 점이었다. 물론 Pull Request에서 #(issue 번호)를 내용에 입력하거나 commit message에 #(issue 번호)를 남겨 놓을 경우 해당 issue까지 같이 close되어 둘 다 Done으로 옮겨지기 때문에 큰 문제는 없을 것 같아서 이대로 하기로 하였다.
해당 동작은 Github project 내에서 제공되는 workflow 기능을 통해 구현할 수 있었다.
프로젝트 창 우상단에 있는 위 버튼을 클릭한 후,
첫번째에 있는 Workflows를 선택해서 들어가면 위 동작들을 직접 설정할 수 있는 페이지가 열린다. 원래는 Pull Request는 Review Requested로 가고, 일반 issue는 Todo에 가도록 하고 싶었는데 둘을 나누는 법을 찾지 못해서 둘 다 Todo로 보내는 것으로 만족할 수밖에 없었다. Github Actions를 활용하면 할 수 있을 것 같았지만 개발 목표 기간이 겨울까지로 목표 내로 출시하는 것이 여유롭지 않을 것 같아 이 이상을 투자할 수는 없어 아쉬웠다.
다음 목표
이제 Issue들과 Pull Request의 진행 상황을 한 눈에 볼 수 있게 되었다. 개발자가 둘밖에 없어서 복잡하지는 않겠지만, 이제 branch를 어떻게 쓰고 어떤 절차를 거쳐서 개발을 할 지 개발 프로세스를 세워 볼 것이다.
