Review apps
리뷰 앱은 제품 변경 사항을 쇼케이스할 환경을 제공하는 협업 도구입니다.
참고: 쿠버네티스 클러스터가 있는 경우 Auto DevOps를 사용하여 애플리케이션에서 이 기능을 자동화할 수 있습니다.
리뷰 앱:
- 기능 브랜치에서의 변경 사항을 자동 라이브 프리뷰로 제공하여 머지 요청을 위한 동적 환경을 생성합니다.
- 디자이너 및 제품 관리자가 귀하의 변경 사항을 브랜치를 체크아웃하거나 샌드박스 환경에서 실행할 필요 없이 확인할 수 있습니다.
- GitLab DevOps LifeCycle와 완전히 통합되어 있습니다.
- 변경 사항을 원하는 위치에 배포할 수 있습니다.
이전 예시에서:
- 커밋이
topic branch
에 푸시될 때마다 리뷰 앱이 빌드됩니다. - 리뷰어는 세 번째 리뷰를 통과하기 전에 두 번의 리뷰를 실패합니다.
- 리뷰가 통과되면
topic branch
가 기본 브랜치에 병합되어 스테이징에 배포됩니다. - 스테이징에서 승인되면 기본 브랜치로 병합된 변경 사항이 프로덕션에 배포됩니다.
리뷰 앱 작동 방식
리뷰 앱은 환경과의 매핑입니다. 리뷰 앱에 대한 액세스는 브랜치에 관련된 병합 요청의 링크로 이용할 수 있습니다.
다음은 동적으로 설정된 병합 요청의 예시입니다.
이 예에서:
- 성공적으로 빌드되었습니다.
- 앱 보기를 선택하여 접근할 수 있는 동적 환경에 배포되었습니다.
리뷰 앱을 워크플로우에 추가한 후에는 브랜치 Git 플로우를 따릅니다. 즉,
- 브랜치를 푸시하고 러너가
script
정의에 따라 리뷰 앱을 배포하도록 합니다. - 러너가 웹 애플리케이션을 빌드하고 배포하기를 기다립니다.
- 변경 사항을 실시간으로 보려면 브랜치에 관련된 병합 요청의 링크를 선택합니다.
리뷰 앱 구성
리뷰 앱은 동적 환경에 구축되며, 각 브랜치를 위한 새로운 환경을 동적으로 생성할 수 있도록 합니다.
리뷰 앱을 구성하는 과정은 다음과 같습니다:
- 리뷰 앱을 호스팅하고 배포할 인프라를 설정합니다(예시를 확인하세요).
- 배포를 위해 러너를 설치하고 구성합니다.
-
.gitlab-ci.yml
에 새로운 환경을 생성하며 브랜치에서만 실행되도록 사전 정의된 CI/CD 변수${CI_COMMIT_REF_SLUG}
를 사용하는 작업을 설정합니다. 또는 프로젝트에서 리뷰 앱 활성화를 사용하여 이 작업에 대한 YAML 템플릿을 얻을 수 있습니다. - 선택적으로 리뷰 앱을 수동으로 중지하는 작업을 설정합니다.
리뷰 앱 활성화 버튼
- GitLab 12.8에 소개되었습니다.
프로젝트에 리뷰 앱을 구성할 때, 앞서 언급된대로 .gitlab-ci.yml
파일에 새로운 작업을 추가합니다.
이를 위해 쿠버네티스를 사용하고 있다면, 리뷰 앱 활성화를 선택하고 GitLab이 당신에게 템플릿 코드 블록을 제공하여
해당 코드를 .gitlab-ci.yml
에 복사하여 붙여넣을 수 있습니다.
전제 조건:
- 프로젝트에 대한 최소한의 개발자 역할이 필요합니다.
리뷰 앱 템플릿 사용 방법:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 리뷰 앱 작업을 생성하려는 프로젝트를 찾습니다.
- 운영 > 환경을 선택합니다.
- 리뷰 앱 활성화를 선택합니다.
-
제공된 코드 스니펫을 복사하여
.gitlab-ci.yml
파일에 붙여넣습니다:
이 템플릿은 필요에 따라 편집할 수 있습니다.
리뷰 앱 자동 중지
일정 시간이 경과한 후에 환경을 종료 및 자동 중지하도록 리뷰 앱 환경을 구성하는 방법을 확인하세요.
리뷰 앱 예시
다음은 리뷰 앱 구성을 보여주는 예시 프로젝트입니다:
리뷰 앱의 다른 예시:
라우트 맵
라우트 맵을 사용하면 리뷰 앱을 위해 정의된 환경에서 소스 파일에서 곧바로 공용 페이지로 이동할 수 있습니다.
설정한 후에는 병합 요청 위젯의 리뷰 앱 링크를 선택하여 변경된 페이지로 직접 이동하여 제안된 수정 사항을 미리 볼 수 있어 더 쉽고 빠르게 미리 볼 수 있습니다.
라우트 맵 구성은 리포지토리의 파일 경로와 웹 사이트의 페이지 경로를 라우트 맵을 사용하여 GitLab에 알리는 것을 포함합니다. 라우트 맵을 구성하고 나면 보기 버튼이 표시됩니다. 이러한 버튼을 선택하여 병합 요청에서 직접 변경된 페이지로 이동합니다.
라우트 맵을 설정하려면 .gitlab/route-map.yml
경로에 있는 리포지토리 내에 파일을 추가해야 합니다. 해당 파일에는 source
경로(리포지토리 내)와 public
경로(웹 사이트 상)를 매핑하는 YAML 배열이 포함되어야 합니다.
라우트 맵 예시
다음은 Middleman을 사용하여 GitLab 웹 사이트를 구축하는 데 사용되는 정적 사이트 생성기(SSG)로, GitLab.com의 해당 프로젝트에서 배포된 라우트 맵의 예시입니다.
# 팀 데이터
- source: 'data/team.yml' # data/team.yml
public: 'team/' # team/
# 블로그 게시물
- source: /source\/posts\/([0-9]{4})-([0-9]{2})-([0-9]{2})-(.+?)\..*/ # source/posts/2017-01-30-around-the-world-in-6-releases.html.md.erb
public: '\1/\2/\3/\4/' # 2017/01/30/around-the-world-in-6-releases/
# HTML 파일
- source: /source\/(.+?\.html).*/ # source/index.html.haml
public: '\1' # index.html
# 다른 파일
- source: /source\/(.*)/ # source/images/blogimages/around-the-world-in-6-releases-cover.png
public: '\1' # images/blogimages/around-the-world-in-6-releases-cover.png
매핑은 루트 YAML 배열의 항목으로 정의되며 -
접두사로 식별됩니다. 항목 내에서 두 개의 키를 가진 해시 맵이 있습니다.
-
source
- 정확한 일치를 위한
'
로 시작하고 끝나는 문자열. - 패턴 일치를 위한
/
로 시작하고 끝나는 정규 표현식:- 정규 표현식은 전체 소스 경로와 일치해야 합니다.
^
및$
앵커가 의미합니다. -
()
로 표시된 캡처 그룹을 포함하여 참조할 수 있는 정규 표현식입니다. - 슬래시(
/
)는\/
로 이스케이프할 수도 있고 그럴 필요가 없을 수도 있습니다. - 리터럴 점(
.
)은\.
로 이스케이프해야 합니다.
- 정규 표현식은 전체 소스 경로와 일치해야 합니다.
- 정확한 일치를 위한
-
public
:'
로 시작하고 끝나는 문자열- 발생 순서대로
source
정규 표현식에서 캡처 그룹을 참조하는데 사용되는\N
표현식을 포함합니다.
- 발생 순서대로
소스 경로에 대한 공용 경로는 해당 소스 경로와 일치하는 첫 번째 source
표현식을 찾아 적절한 경우 ()
캡처 그룹의 값으로 public
경로로 반환됩니다.
위의 예시에서 모핑이 정의된 순서대로 계산된다는 사실을 이용하여 source/index.html.haml
이 /source\/(.+?\.html).*/
대신에 /source\/(.*)/
를 일치시키고 index.html
대신에 index.html
로 공용 경로가 결정됩니다.
라우트 매핑이 설정된 후에는 다음 위치에서 이를 활용할 수 있습니다:
- 병합 요청 위젯:
- 비교 또는 커밋을 위한 차이점:
- 파일 옆의 View ()를 선택함으로써 외부 링크를 통해 확인할 수 있습니다.
- Blob 파일보기:
- 파일 옆의 View ()를 선택함으로써 외부 링크를 통해 확인할 수 있습니다.
시각적 리뷰 사용하기
시각적 리뷰가 구성된 후에 리뷰 앱에 시각적 리뷰 피드백 양식이 모든 페이지의 오른쪽에 오버레이됩니다.
병합 요청에서 피드백 양식을 사용하여 코멘트를 남기려면:
- 페이지 오른쪽에서 리뷰 탭을 선택합니다.
- 시각적 리뷰에 코멘트를 달 수 있습니다. 여기서 머지 요청 코멘트에서 사용할 수 있는 마크다운 주석을 사용할 수 있습니다.
- 개인 정보를 입력합니다.
- 만약
data-require-auth
가true
이면 개인 액세스 토큰을 입력해야 합니다. - 그렇지 않으면 이름을 입력하고 선택적으로 이메일을 입력합니다.
- 만약
- 피드백 보내기를 선택합니다.
시각적 리뷰를 실제로 보려면 시각적 리뷰 보기를 참조하세요.
시각적 리뷰를 위한 리뷰 앱 구성
피드백 양식은 리뷰 앱의 페이지에 추가하는 스크립트를 통해 제공됩니다.
이는 응용 프로그램의 <head>
에 추가되어야 하며
일부 프로젝트 및 머지 요청별 값으로 구성됩니다. GitLab.com 프로젝트에 호스팅된 코드를 사용하는 프로젝트에서는 다음과 같습니다:
<script
data-project-id='11790219'
data-merge-request-id='1'
data-mr-url='https://gitlab.com'
data-project-path='sarah/review-app-tester'
data-require-auth='true'
id='review-app-toolbar-script'
src='https://gitlab.com/assets/webpack/visual_review_toolbar.js'>
</script>
이상적인 경우, 각 리뷰 앱이 생성될 때 CI/CD 변수를 사용하여 이러한 값을 런타임에 대체해야 합니다.
-
data-project-id
는 프로젝트 ID로,CI_PROJECT_ID
변수에서 찾을 수 있거나 프로젝트 개요 페이지에서 찾을 수 있습니다. -
data-merge-request-id
는 머지 요청 ID로,CI_MERGE_REQUEST_IID
변수에서 찾을 수 있습니다.CI_MERGE_REQUEST_IID
는rules:if: $CI_PIPELINE_SOURCE == "merge_request_event
를 사용하고 머지 요청이 생성된 경우에만 사용할 수 있습니다. -
data-mr-url
은 GitLab 인스턴스의 URL이며, 모든 리뷰 앱에 대해 동일합니다. -
data-project-path
는 프로젝트 경로로,CI_PROJECT_PATH
에서 찾을 수 있습니다. -
data-require-auth
는 공개 프로젝트에는 선택 사항이지만 비공개 및 내부 프로젝트에는 필수입니다. 이 값이true
로 설정된 경우 사용자는 이름과 이메일 대신에 개인 액세스 토큰을 입력해야 합니다. -
id
는 항상review-app-toolbar-script
이며, 그대로 둘 필요가 없습니다. -
src
는 리뷰 툴바 스크립트의 소스로, 해당 GitLab 인스턴스에 있으며 모든 리뷰 앱에 대해 동일합니다.
예를 들어, GitLab.com 프로젝트에 코드가 호스팅된 Ruby 애플리케이션의 경우 다음과 같은 스크립트가 필요합니다:
<script
data-project-id="ENV['CI_PROJECT_ID']"
data-merge-request-id="ENV['CI_MERGE_REQUEST_IID']"
data-mr-url='https://gitlab.com'
data-project-path="ENV['CI_PROJECT_PATH']"
id='review-app-toolbar-script'
src='https://gitlab.com/assets/webpack/visual_review_toolbar.js'>
</script>
그럼 GitLab CI/CD를 통해 앱이 배포될 때마다 이러한 변수가 실제 값으로 대체되어야 합니다.
머지 요청 ID 결정
시각적 리뷰 도구는 리뷰 앱에 추가된 script
HTML 태그의 data-merge-request-id
데이터 속성에서 머지 요청 ID를 검색합니다.
시각적 리뷰 앱에 연결할 머지 요청을 위한 ID를 결정한 후, ID를 다음 중 하나로 제공할 수 있습니다:
- 앱의 스크립트 태그에 하드코딩합니다.
data-merge-request-id
데이터 속성을 통해. - 앱이 빌드되는 동안 동적으로
data-merge-request-id
값을 추가합니다. - 앱의 시각적 리뷰 양식을 통해 수동으로 제공합니다.
만약 script
에서 ID가 누락된 경우, 시각적 리뷰 도구는 피드백을 제공하기 전에 머지 요청 ID를 입력하도록 요구합니다.
시각적 리뷰용 인증
- GitLab 12.10에서 도입되었습니다.
개인 및 내부 프로젝트에서 시각적 리뷰를 활성화하려면 data-require-auth
변수를 true
로 설정하세요. 활성화된 경우, 사용자는 피드백을 제출하기 전에 api
범위를 갖는 개인 액세스 토큰을 입력해야 합니다.
이와 같은 방법은 모든 공개 프로젝트에 대해 인증을 요구하는 데 사용할 수 있습니다.