지난 MergeRequest로 개발 협업하기를 끝으로 디자이너, 개발자, PM이 서로 커뮤니케이션하고 협업하는 과정을 배워봤습니다.
하지만 구체적으로 뭐가 좋은지 아직 감이 안 잡히는 분들도 계실 겁니다.
그래서 역할별로 MR(Merge Request)의 장점을 총정리하는 시간을 가져 보겠습니다.
이전편은 아래 링크에서 확인하세요.
Merge Request 장점.
# 프로젝트 매니저의 장점
- 프로젝트 매니저는 백로그에 대한 모든 작업 내용과 진행 상 황을 MR 한곳에서 확인할 수 있습니다.
- 요구사항 변경이 일어나면 수정을 해야 하고 그 수정을 다른 사람에게 알려야 하지만 이런 과정들을 모두 MR에서 해결할 수 있습니다. 그리고 진행 상황과 결과물을 보면서 커뮤니케이션 또한 가능합니다.
- 개발 코드에 대한 빌드, 테스트 등을 파이프라인 결과로 확인할 수 있고, 산출물 또한 확인할 수 있습니다.
- Merge 승인을 통해, 실제 적용에 대한 권한 수행을 할 수 있습니다.
# 비개발자(디자이너, 기획자)의 장점
- 업무 진행에 따른 모든 변경 사항에 대한 히스토리를 한곳에서 확인하고 추적할 수 있습니다.
- 커뮤니케이션과 작업물 공유를 이슈와 MR에서 모두 해결할 수 있습니다.
- 배포 파이프라인을 통해 굳이 누군가에게 요청할 필요 없이 결과물을 확인할 수 있습니다.
- 연관된 이슈를 묶어 추적성을 얻을 수 있어, 업무 연계성도 높일 수 있습니다.
# 개발자의 장점
- 요구사항과 디자인 결과물에 대한 변경 사항을 한곳에서 트래킹하면서 개발을 진행할 수 있습니다.
- 배포 파이프라인이 디자이너, 기획자에게 결과물을 공유하므로, 이것으로 다음 작업에 대한 피드백을 받을 수 있습니다.
- 테스트 파이프라인으로 사전 버그 체크에 대한 작업을 자동화할 수 있습니다.
- 코드 리뷰와 간단한 코드 수정을 한 곳에서 할 수 있습니다.
여기까지 MR의 장점을 정리해 보았습니다.
GitLab은 MR을 직접 사용하여 협업하고 발전시켜 가고 있습니다.
개인적으로 MR를 사용하면서 느낀 장점은 '많지도 적지도 않은 기능을 필요한 만큼 적당히 넣어뒀다는 점'입니다.
많은 분들이 GitLab을 단지 저장소로만 사용하거나 MR의 기능은 알고는 있지만 활용하지 않는 것으로 알고 있습니다.
분명 MR을 위한 정책을 만드는 것에는 피곤함과 불편함이 뒤따를 수 있습니다.
그러나 협업을 위해 적극적으로 MR을 활용한다면 강력한 협업 도구가 될 수 있습니다.
지금까지 진행한 모든 예제는 아래 링크에서 다시 확인할 수 있습니다!
예제 링크: https://gitlab.com/infograb-public/gitlab/mr-sample