팀 협업 중에 코드 품질 때문에 이슈가 발생하는 경우가 있나요? 소프트웨어 개발 문화가 성숙할수록 코드리뷰 활동도 성숙해집니다. 다른 사람이 작성한 코드를 보고 개선을 위한 의견을 주고 받는 활동을 합니다. 코드 리뷰는 코드로 협업하는 개발팀이 리뷰를 통해 잠재적인 이슈를 해결하고 개선해 나가는 과정입니다. 소프트웨어 개발 라이프사이클에서 소프트웨어 품질 보증 활동의 시작은 코드 리뷰 활동입니다.
그렇다면, GitLab으로 코드 리뷰를 더 잘하는 방법은 어떨까요?
항상 처음 보다 더 나은 상태로 코드를 만들어 놓고 떠나라
- Robert C. Martin (Uncle Bob) , 보스카웃룰 패러디
GitLab 워크플로우
<GitLab의 일반적인 워크플로우>
GitLab의 개발 라이프사이클은 이슈 아이템으로 요건이나 수정해야 할 버그를 등록하는 것으로 시작됩니다. 개발자는 자신에게 할당된 이슈 아이템을 확인하고 신규 Feature 브랜치를 생성합니다. 신규 브랜치에서 이슈 아이템을 처리하기 위한 커밋 활동을 반복적으로 하며, 어느 정도 완성이 되면 GitLab 서버로 브랜치를 Push 합니다.
Push 되면 GitLab CI가 해당 브랜치에 대한 빌드 파이프라인이 구동됩니다. 파이프라인에서 테스트를 포함한 빌드와 검증이 완료되면, Merge Reauest(MR)을 생성하여 변경사항을 타겟 브랜치(보통은 master나 develop)로 머지를 요청합니다. 바로 지금부터가 GitLab 에서 코드 리뷰가 시작되는 지점입니다. 병합요청(Merge request)은 GitLab에서의 코드를 통한 협업 시작지점입니다. 이름처럼 브랜치에서 다른 브랜치로 병합하는 것이 Merge Request입니다. Merge Request로 의미 있는 코드의 변화를 리뷰하는 팀원들에게 알리고 협업할 수 있습니다. Merge Request 페이지에는 코드에 대한 변경사항과 그 변경으로 발생한 CI/CD 파이프라인 정보 그리고 리뷰에 참여한 사람들의 커멘트 스레드를 이용하여 리뷰가 진행됩니다.
<Merge Request 예시 화면>
위에 화면에 보이는 것처럼 Merge Request는 코멘트를 이용한 논의, commit 목록, 파이프라인 및 관련 이슈 확인, 코드 변경에 대한 인라인 리뷰를 할 수 있는 탭이 포함되어 있습니다.
GitLab CE, EE (Premium 이상)에 따라서 리뷰와 관련 기능이 조금씩 다르며 그에 대한 내용은 다음과 같습니다.
GitLab CE의 기본 코드 리뷰 관련 기능을 활용하기
Merge Request 템플릿 활용하기
MR의 내용을 일관되게, 팀의 합의된 룰에 맞게 의사소통하기 위해 템플릿을 만들어서 쓸 수 있습니다. 레파지토리 내에 .gitlab/merge_requests_template/템플릿명.md 파일을 생성하면 아래와 같이 템플릿을 선택할 수 있습니다. (이슈 템플릿을 만드는 것과 유사합니다. 이슈 템플릿은 .gitlab/issue_template/템플릿명.md 을 사용합니다.)
Merge Request API 활용하기
API를 통해 GitLab을 자동화할 수 있습니다. MR 생성되었을 때, Approval 되었을 때, Merge 되었을 때 모든 이벤트가 API로 제공되어 자동화에 간단히 활용할 수 있습니다.
파이프라인이 성공하면 Merge 하기
MR을 처리할 준비가 되었지만, 아직 하나 이상의 CI Job이 실행 중이라면 Merge when pipeline success 버튼을 통해 CI의 Job이 완료될 때까지 기다릴 필요없이 완료 후 자동으로 Merge를 수행하게 됩니다.
Work in Progress (WIP) 로 Merge Request 가시화 하기
MR 이 작업 진행 중(WIP: Working In Progress) 상태가 되면 준비되기 전에 실수로 Merge 되는 것을 방지할 수 있습니다. 준비가 완료 되었다는 것은 Resolve WIP 를 해야합니다.
담당자 (Assignee) 정하기
MR에 대한 담당자(Assignee)를 지정하여 MR에 대한 오너쉽을 부여합니다.
Merge Request 에서 commit 내용 리뷰하기
MR 화면 안에서 커밋에 대한 커멘트로 리뷰를 할 수 있습니다.
- 인라인 커멘트를 만들고 해결하기
변경에 대해 인라인 커멘트를 통해 의견을 개진할 수 있습니다. Review 남긴 내용이 모두 완료되지 않으면 Merge 할 수 없습니다. 따라서 협업시에 의견을 모두 볼 수 밖에 없는 구조가 만들어 집니다.
- Suggest Changes를 통해 코드 변경사항을 코드로 제안하기
단지 의견이 아니라 코드 자체를 수락할 수 있도록 만들 수 있습니다. Suggest Changes를 통해 가능하며, 리뷰어는 수용할 때 한 번의 클릭으로 제안받은 코드를 병합할 수 있습니다. 12.7 버전부터 사용할 수 있는 기능입니다.
- diff에 대한 하이라이팅으로 쉽게 변경사항 보기
제안받은 코드의 차이점도 diff로 하아라이팅 됩니다. 따라서 어떤 단어, 혹은 문자가 변경되었는지 명확하게 알고 Apply suggestion 버튼을 통해 제안사항을 반영할 수 있게 됩니다.
- Diff 파일 네비게이션하기
Changes 탭에서는 MR 요청에 변경된 전체 파일 목록을 트리로 확인할 수 있으며, 해당 파일을 선택하여 필터링하여 Diff를 내비게이션 할 수 있습니다.
- 이미지가 포함되어 있을 경우 이미지 자체에 커멘트 작성하기
이미지가 포함된 경우 이미지 위에 클릭하면 풍선 아이콘이 생기고 커멘트를 작성할 수 있습니다.
- Merge Request 가 배포된 환경(Environment) 별로 배포된 내용 확인하기
Merge Request에서 파이프라인이 완료되고 나면 연관된 배포 환경(Environment)에 대한 배포 시간을 표시합니다. 여러 이해관계자는 코드의 변경뿐만 아니라 코드로 인해 특정 배포 환경에 배포된 내용까지 한 번에 따라서 확인할 수 있게 됩니다.
GitLab EE의 코드 리뷰 관련 기능 활용하기
Premium의 기능
- Merge Request Review 기능
여러개의 리뷰 의견에 대해 임시로 초안을 작성하고 한 번에 리뷰를 등록할 수 있는 기능을 사용할 수 있습니다.
- 코드 리뷰를 이용한 Approval Rule 활용
각각의 MR에 대해 적합한 승인자 목록과 최소 승인자 수를 지정할 수 있습니다. 모든 MR을 특정 개인이 승인하도록 하려면 개인을 승인자로 설정하고 최소 승인 수를 1로 설정할 수 있습니다. 프로젝트에서 설정된 MR에 대한 승인 규칙은 타겟 브랜치에 따라 선택적으로 적용될 수 있습니다.
- Protected 브랜치에 대한 Approval Rule 적용
리뷰에 대한 승인률은 종종 master와 같은 특정 브랜치에만 연관이 있습니다. 기본 Approval 룰을 구성 할 때 특정 Protected Branch 나, 모든 Protected Branch로 적용되도록 설정할 수 있습니다.
- Merge Request 의존성 관리
MR이 동일 프로젝트나 다른 프로젝트에서 발생 될 때, Merge 순서를 조정할 수 있습니다.
- 코드 소유자(Code Owner)에 의해 Protected 브랜치 approval 기능
Protected Branch에 대한 MR 요청의 경우 한 명 이상의 코드 오너가 필요하도록 설정할 수 있습니다.
인포그랩은 조직의 개발라이프사일클과 도구의 Fit을 빠르게 맞출수 있도록 돕습니다. 어떻게 하면 좀더 높은 품질의 코드를 협력적으로 생산해 낼 수 있을까요? 교육을 시작으로 한번 해보며, 반복적으로 해서 문화가 만들어져야 합니다. 오른쪽 상단에 문의하기를 통해 필요하신 사항을 알려주세요.