Merge Request를 통한 협업

MR에는 브랜치를 만들고 Merge 또는 구현을 요청, CI/CD를 통한 Test의 결과를 확인하고 코드 리뷰 후 팀으로부터 피드백을 받고 최종적으로 관리자로부터 Merge Request에 대한 승인과 Merge에 대한 파이프라인의 성공과 변경사항 적용까지 팀원들이 진행사항을 파악하여 협업하도록 모든 기록을 보고 audit할 수 있습니다.

MR의 사용 예시​

개발자:

  • 새 브랜치를 체크 아웃하고 MR을 통해 변경 사항 제출
  • 피드백(코드 리뷰) 받기
  • 웹 프로젝트라면, Review Apps로 변경 사항을 미리 볼 수 있습니다.
  • 코드 품질 보고서(Code Quality Reports)로 코드를 최적화하는 구현 작업을 수행
  • GitLab CI / CD의 단위 테스트 보고서로 변경 사항을 확인합니다.
  • 라이선스 준수 보고서를 통해 라이선스가 프로젝트와 호환되지 않는 종속성을 사용하지 않습니다.
  • 관리자에게 승인 을 요청합니다.

운영 :

  • 최종 검토와 함께 커밋을 푸시
  • MR을 승인
  • 파이프라인이 성공하면 Merge 실행
  • 변경 사항은 GitLab CI / CD 작업을 통해 프로덕션에 배포

MR 만들기​

1. MR 브랜치 준비하기​

photo | 인포그랩 GitLab | 인포그랩 GitLab

로컬에서 새 브랜치를 체크 아웃하여 푸쉬하거나 웹 UI에서 브랜치를 새로 생성하면, Project overview, Repository > Files, Merge Requests 메뉴에서 위 그림의 네모 칸과 같은 알림이 나타납니다. MR을 생성하기 위해서 'Create merge request' 버튼을 클릭합니다. 만약, 이전에 만든 브랜치로 MR을 생성하려면 위 그림 하단의 'New merge request' 버튼을 클릭하여 진행합니다.

(이슈를 통해 MR을 생성하는 방법은 디자이너와 개발자가 협업하는 방법 참고)

2. MR 작성​

photo | 인포그랩 GitLab | 인포그랩 GitLab
옵 션설 명
** Title **MR의 제목을 입력합니다.
** Description **MR을 통한 변경사항의 목적과 검토자가 확인해야 할 항목을 기술합니다.
** Assignee **해당 MR의 담당자 선택
** Milestone **MR의 마일스톤 선택
** Labels **MR의 레이블 선택
** Merge request dependencies(PREMIUM) **#merge-request-dependencies
** Approval rules **MR에 대한 승인권자를 설정합니다.
** Merge options **'Delete source branch when merge request is accepted'에 체크하면 현재 MR의 브랜치를 제거하면서 Merge를 실행합니다. 'Squash commits when merge request is accpeted'에 체크하면 MR에 쌓여있는 커밋 리스트를 하나의 커밋으로 묶어서 Merge를 실행합니다.

MR 사용하기​

1. 리뷰​

photo | 인포그랩 GitLab | 인포그랩 GitLab

변경사항 좌측에 마우스를 올리면 말풍선 버튼이 나타납니다. 클릭하여 리뷰를 쓴 후 'Start a review' 버튼을 클릭하여 리뷰를 진행합니다.

(더 자세한 내용은 코멘트와 쓰레드로 토론하기를 참고)

2. 승인​

photo | 인포그랩 GitLab | 인포그랩 GitLab

위 그림에서 MR의 Merge 버튼을 활성화 시키기 위해서는 2명의 승인이 필요합니다. 코드 리뷰와 승인을 받는 과정은 팀원들이 파이프라인의 진행 상황을 명확하게 파악할 수 있고 협업하도록 도와주는 중요한 역할을 합니다.

(Merge Requset Approvals 설정에 대한 자세한 내용은 Merge Request Approvals를 참고)

3. 실행​

photo | 인포그랩 GitLab | 인포그랩 GitLab

Merge를 하기 위해 필요한 수의 승인을 받고 나면 Merge 버튼이 활성화되고 버튼을 클릭하여 Merge를 실행할 수 있습니다. Merge를 실행하기 전 두 가지 옵션을 체크할 수 있습니다. 'Delete source branch'에 체크하면 현재 MR의 브랜치를 제거하면서 Merge를 실행합니다. 'Squash commits'에 체크하면 MR에 쌓여있는 커밋 리스트를 하나의 커밋으로 묶어서 Merge를 실행합니다.

(Merge 권한을 설정하려면 Protected Branch를 참고)

MR에 테스트 추가하기​

MR의 변경 사항에 대한 테스트 결과를 통해 코드 리뷰를 진행하면 검토자와 QA 팀의 시간을 절약할 수 있습니다.

파이프라인​

해당 MR의 브랜치에 커밋이 발생하면 파이프라인이 테스트를 수행합니다. 아래 그림과 같이 테스트가 통과되면 passed, 실패하면 failed를 표시합니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

파이프라인에 MR과정 중 테스트를 삽입하려면, gitlab-ci.yml에 테스트 스크립트와 함께 'only: - merge_request' 파라미터를 입력합니다.

예시:

test:
  stage: test
  script: ./test
  only:
    - merge_requests

코드 품질 위젯​

GitLab CI/CD로 GitLab Code Quality를 사용하여 소스 코드 품질을 분석 할 수 있습니다. GiLab은 무료 오픈 소스 인 Code Climate Engine을 사용합니다. MR에서 다음과 같이 코드 품질 보고를 받을 수 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

브라우저 성능 테스트​

PREMIUM

웹 프로젝트는 CI/CD를 통해 렌더링 퍼포먼스 테스트를 할 수 있습니다. GitLab은 무료 오픈 소스 도구 인 Sitespeed.io를 사용하여 웹 사이트의 렌더링 성능을 측정합니다. GitLab에서 빌드 한 Sitespeed 플러그인은 browser-performance.json이라는 파일에서 분석 된 각 페이지의 성능 점수를 출력합니다. 그리고 이 데이터는 MR에 표시 될 수 있습니다.

photo | 인포그랩 GitLab | 인포그랩 GitLab

MR에 대한 권한​

Protected Branch를 통해 프로젝트 관리자는 관리자 액세스 권한을, 일반 개발자는 개발자 액세스 권한을 얻습니다. 관리자가 Protected Branch를 설정하면 해당 브랜치는 'Protected'로 표시됩니다. Protected Branch를 설정하면, 개발자는 새 feature 브랜치를 프로젝트에 푸시하고 MR을 작성하거나 다른 팀원의 변경사항을 검토 합니다. 그리고 관리자 권한이 있는 사용자만 변경 사항을 Protected Branch에 Merge 할 수 있습니다.

참고: Protected Branches

Merge Request dependencies​

라이선스: PREMIUM

단일 논리적 변경이 여러 MR에 걸쳐 있고 여러 프로젝트에 분산되는 것이 일반적이며 Merge되는 순서가 중요 할 수 있습니다. Merge Request dependencies를 사용하면 MR간에 필요한 Merge 순서를 정할 수 있습니다. Merge Request dependencies에 다른 MR을 설정 했을 경우 종속성에 걸린 MR이 Merge 될 때까지 Merge 할 수 없습니다.

사용 예시:

  • 라이브러리를 가져오는 프로젝트를 변경하기 전에, 라이브러리 변경 사항이 Merge 되었는지 확인이 필요할 때
  • 문서화 할 기능을 구현하는 MR 전에 문서 내용에 관한 MR이 Merge되지 않도록 해야 할 때