들어가며
최근 진행하게 된 프로젝트에서는 깃랩을 이전보다 더 활용 해 보기로 하였습니다. 깃랩은 Git 저장소 관리의 역할뿐 아니라 협업을 위한 여러 가지 기능들을 제공하고 있는데 그동안은 Git을 통한 소스 관리는 자주 사용했었지만 깃랩과 연계하여 프로젝트를 관리한 경험은 많지 않았었습니다. 이번 기회에 한번 사용해 보기로 했고 나름의 중점 사항을 체크하여 적용해 보고 사용한 경험을 공유해 보려고 합니다.
저의 경험이 모두에게 옳거나 맞는 방법은 아닐 수 있습니다. 다만, 다양한 사례들이 공유되면서 사용자 본인에게 적당한 방법을 찾아갈 수 있는 하나의 이정표가 될 수는 있다고 생각하고 있습니다. 그 점을 기억해 주시면서 읽어 주시면 감사하겠습니다.
프로젝트 개요 정리
전반적인 프로젝트의 개요, 모든 구성원들에게 공유되어야 하는 일반적인 정보들은 프로젝트 README.md 파일에 정리하였습니다. 프로젝트 대문에 표시되기 때문에 접근이 편리하다는 장점이 있었습니다.
마일스톤
먼저, 주어진 과업의 큰 틀은 마일스톤으로 등록하여 관리하였습니다. 마일스톤의 개념은 프로젝트가 진행되면서 달성해야 하는 주요한 목표 내지는 도달점 정도로 이해하고 있는데, 마일스톤의 계획 수립은 전체 일정 관리에서 중요한 부분을 차지한다고 알고 있습니다. 이번에는 명확하게 제시된 기능 개발의 일정과 범위가 있었기 때문에 해당 범위들을 마일스톤으로 정의했습니다. 마일스톤 화면에서는 연결된 이슈, 머지 리퀘스트, 라벨 등을 한눈에 볼 수 있기 때문에 진척률 관리의 지표로 삼을 수 있습니다.
이슈
마일스톤이 등록되었다면 각 마일스톤의 세부 일정은 이슈로 관리하기로 했습니다. 개발 범위가 할당된 구성원은 목표에 맞게 이슈 제목을 정하고 Due Date 등 기본사항들을 입력합니다. 이때, 제목은 브랜치와도 연계되기 때문에 최대한 간결하면서도 명확하게 작성합니다.
각각의 이슈는 할당된 구성원이 이슈 생성부터 문제 해결, 머지 리퀘스트 전 충돌 여부 점검 등 해당 이슈가 클로즈 되기까지 담당자가 책임지는 명확한 규칙을 정했습니다. 그리고 이슈 진행 중 발견되는 문제 요소들은 댓글과 대댓글로 관리하며 적당한 라벨을 활용하기로 했습니다. 라벨은 기본적으로 등록된 라벨 외에 약속된 규칙에 맞게 몇 가지 더 추가하였습니다.
- feat : 새로운 기능의 개발 또는 기존의 코드를 수정하지 않는 작업
- bug : 버그가 발생했음을 표시하기 위함
- issue : 개발 진행 중 발견된 특이 사항이 있을 경우 사용해서 프로젝트 구성원들에게 이슈가 있음을 알리기 위한 용도
이렇게 이슈 안에서 라벨을 달아놓으면 이슈의 문제 상황에 대해서 전체적으로 점검하기에 편리합니다.
브랜치와 커밋
브랜치 관리
Git 저장소의 핵심 기능인 브랜치는 이슈와 1:1로 매칭 되게 끔 관리하기로 규칙을 정했습니다. 브랜치의 제목은 생성 시 깃랩 자체적으로 이슈 제목과 연계된 브랜치 제목을 디폴트로 설정해 주는데, 이것을 그대로 사용하기로 하였습니다. 또한 이슈와 연관되지 않은 작업은 해당 브랜치에서 진행하지 않는 것을 기본 규칙으로 하였습니다. 때에 따라서는 번거로운 방법이 될 수 있겠으나 이슈 구분의 목적을 명확하게 하기 위함이었습니다.
커밋메시지는 정확하게!
커밋 메시지의 통일에 대한 중요함은 다들 잘 알고 계실 텐데 제가 이번에 적용한 규칙은 다음과 같았습니다.
- feat : 라벨과 동일한 개념의 커밋 메시지. 새로운 기능의 추가.
- fix : 버그 수정
- docs : 문서를 수정하는 경우
- style : 코드 포맷팅을 수정하는 경우
- refactor : 코드 리펙토링 관련 작업의 경우
- chore : 빌드 관련 또는 패키지 매니저가 수정되는 경우
실제로 작업을 하다 보니 어떤 키워드가 더 목적과 일치하는지 판단을 하는 것도 어려울 때가 많았습니다. 때문에 커밋은 비슷한 성격의 작업 또는 정확한 목표를 바라보는 작업을 묶음으로 최대한 쪼개서 등록하는 것이 좋습니다.
머지 리퀘스트와 코드 리뷰
머지 리퀘스트의 기본 정책
작업자 본인이 판단했을 때, 할당된 범위의 모든 개발이 완료되었고 자체 검수까지 진행되었다면 머지 리퀘스트를 생성합니다. 작업자는 머지 리퀘스트 이전에 브랜치에 충돌 사항은 없는지 스스로 검수하고, 만약 충돌이 발생했다면 스스로 해결하는 것을 기본 원칙으로 삼았습니다.
코드 리뷰
머지 리퀘스트가 생성되면 리뷰어는 코드 리뷰를 진행합니다. 개발된 코드를 전체적으로 점검하고 수정이 필요해 보이는 부분은 스레드를 남깁니다. 이렇게 남긴 스레드는 취합되어 표시되기 때문에 코드 리뷰의 진행 상황을 한눈에 알 수 있습니다. 모든 스레드가 해결되면 비로소 Approved가 가능해지고 리뷰어는 머지를 실행할 수 있습니다. 머지와 동시에 이슈와 브랜치를 닫을 건지 선택할 수 있는데 저는 이슈만 닫고 브랜치는 남겨두었습니다.
✅ 작업 담당자와 리뷰어는 코드 리뷰를 통해서 의견을 교환하고 더 나은 방법을 찾아갑니다. 우정출연 해주신 어느 주임님께 감사드립니다.😄
위키
몇 가지 문법을 활용하여 문서를 생성할 수 있는 위키 메뉴는 저의 경우 각종 체크 리스트 또는 회의록 등을 저장하는 용도로 활용하기로 했습니다. 우리에게 익숙한 마크다운이 기본 문법으로 제공됩니다. 생성된 위키 문서는 프로젝트 구성원 누구라도 수정 가능하며 이력이 남습니다.
스니펫
재활용 가능성이 많아 보이는 코드 조각은 스니펫을 활용하면 구성원들과 공유하기 좋습니다. 저는 이번에는 제대로 활용하지 못한게 아쉽네요.
마치며
처음 계획을 잡고 시도를 할 때만 해도 다양한 부분에서 활용법을 찾아보자고 생각했었는데, 시간이 지나고 보니 그냥 보편적인 기능들만 활용한 것 같네요. 많은 협업과 관리 도구들이 제공되고 있는데 경험해 보지 못한 것이 못내 아쉽긴 합니다. 서론에서도 언급하긴 했지만, 관리 방법의 한 가지 사례로써 이해해 주시길 바라며, 제 글의 취약한 점은 보강하고 좋은 점은 흡수하며 본인 만의 관리 방법을 만들어 가시는 데 도움이 되었으면 좋겠습니다. 또한, 관련되어 프로젝트 관리 방법론에 대한 여러 가지 다양한 의견들이 논의되는 계기가 되었으면 하며 이만 글을 마치겠습니다.