Review apps

티어(Tier): Free, Premium, Ultimate 제공: GitLab.com, Self-managed, GitLab Dedicated

리뷰 앱은 제품 변경 사항을 쇼케이스할 환경을 제공하는 협업 도구입니다.

참고: 쿠버네티스 클러스터가 있는 경우 Auto DevOps를 사용하여 애플리케이션에서 이 기능을 자동화할 수 있습니다.

리뷰 앱:

  • 기능 브랜치에서의 변경 사항을 자동 라이브 프리뷰로 제공하여 머지 요청을 위한 동적 환경을 생성합니다.
  • 디자이너 및 제품 관리자가 귀하의 변경 사항을 브랜치를 체크아웃하거나 샌드박스 환경에서 실행할 필요 없이 확인할 수 있습니다.
  • GitLab DevOps LifeCycle와 완전히 통합되어 있습니다.
  • 변경 사항을 원하는 위치에 배포할 수 있습니다.

이전 예시에서:

  • 커밋이 topic branch에 푸시될 때마다 리뷰 앱이 빌드됩니다.
  • 리뷰어는 세 번째 리뷰를 통과하기 전에 두 번의 리뷰를 실패합니다.
  • 리뷰가 통과되면 topic branch가 기본 브랜치에 병합되어 스테이징에 배포됩니다.
  • 스테이징에서 승인되면 기본 브랜치로 병합된 변경 사항이 프로덕션에 배포됩니다.

리뷰 앱 작동 방식

리뷰 앱은 환경과의 매핑입니다. 리뷰 앱에 대한 액세스는 브랜치에 관련된 병합 요청의 링크로 이용할 수 있습니다.

다음은 동적으로 설정된 병합 요청의 예시입니다.

병합 요청의 리뷰 앱

이 예에서:

  • 성공적으로 빌드되었습니다.
  • 앱 보기를 선택하여 접근할 수 있는 동적 환경에 배포되었습니다.

리뷰 앱을 워크플로우에 추가한 후에는 브랜치 Git 플로우를 따릅니다. 즉,

  1. 브랜치를 푸시하고 러너가 script 정의에 따라 리뷰 앱을 배포하도록 합니다.
  2. 러너가 웹 애플리케이션을 빌드하고 배포하기를 기다립니다.
  3. 변경 사항을 실시간으로 보려면 브랜치에 관련된 병합 요청의 링크를 선택합니다.

리뷰 앱 구성

리뷰 앱은 동적 환경에 구축되며, 각 브랜치를 위한 새로운 환경을 동적으로 생성할 수 있도록 합니다.

리뷰 앱을 구성하는 과정은 다음과 같습니다:

  1. 리뷰 앱을 호스팅하고 배포할 인프라를 설정합니다(예시를 확인하세요).
  2. 배포를 위해 러너를 설치하고 구성합니다.
  3. .gitlab-ci.yml에 새로운 환경을 생성하며 브랜치에서만 실행되도록 사전 정의된 CI/CD 변수 ${CI_COMMIT_REF_SLUG}를 사용하는 작업을 설정합니다. 또는 프로젝트에서 리뷰 앱 활성화를 사용하여 이 작업에 대한 YAML 템플릿을 얻을 수 있습니다.
  4. 선택적으로 리뷰 앱을 수동으로 중지하는 작업을 설정합니다.

리뷰 앱 활성화 버튼

  • GitLab 12.8에 소개되었습니다.

프로젝트에 리뷰 앱을 구성할 때, 앞서 언급된대로 .gitlab-ci.yml 파일에 새로운 작업을 추가합니다. 이를 위해 쿠버네티스를 사용하고 있다면, 리뷰 앱 활성화를 선택하고 GitLab이 당신에게 템플릿 코드 블록을 제공하여 해당 코드를 .gitlab-ci.yml에 복사하여 붙여넣을 수 있습니다.

전제 조건:

  • 프로젝트에 대한 최소한의 개발자 역할이 필요합니다.

리뷰 앱 템플릿 사용 방법:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 리뷰 앱 작업을 생성하려는 프로젝트를 찾습니다.
  2. 운영 > 환경을 선택합니다.
  3. 리뷰 앱 활성화를 선택합니다.
  4. 제공된 코드 스니펫을 복사하여 .gitlab-ci.yml 파일에 붙여넣습니다:

    리뷰 앱 활성화 모달

이 템플릿은 필요에 따라 편집할 수 있습니다.

리뷰 앱 자동 중지

일정 시간이 경과한 후에 환경을 종료 및 자동 중지하도록 리뷰 앱 환경을 구성하는 방법을 확인하세요.

리뷰 앱 예시

다음은 리뷰 앱 구성을 보여주는 예시 프로젝트입니다:

프로젝트 구성 파일
NGINX .gitlab-ci.yml
OpenShift .gitlab-ci.yml
HashiCorp Nomad .gitlab-ci.yml
GitLab Documentation build-and-deploy.gitlab-ci.yml
https://about.gitlab.com/ .gitlab-ci.yml
GitLab Insights .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 app 버튼을 선택하여 .gitlab-ci.yml 파일에 설정된 환경 URL로 이동할 수 있습니다.
    • 목록에는 라우트 맵에서 일치하는 항목 중 처음 5개가 표시되지만 5개 이상의 항목이 있는 경우 이를 필터링할 수 있습니다.

      병합 요청 위젯에서 파일 목록 보기

  • 비교 또는 커밋을 위한 차이점:
    • 파일 옆의 View ()를 선택함으로써 외부 링크를 통해 확인할 수 있습니다.
  • Blob 파일보기:
    • 파일 옆의 View ()를 선택함으로써 외부 링크를 통해 확인할 수 있습니다.

시각적 리뷰 사용하기

시각적 리뷰가 구성된 후에 리뷰 앱에 시각적 리뷰 피드백 양식이 모든 페이지의 오른쪽에 오버레이됩니다.

시각적 리뷰 피드백 양식

병합 요청에서 피드백 양식을 사용하여 코멘트를 남기려면:

  1. 페이지 오른쪽에서 리뷰 탭을 선택합니다.
  2. 시각적 리뷰에 코멘트를 달 수 있습니다. 여기서 머지 요청 코멘트에서 사용할 수 있는 마크다운 주석을 사용할 수 있습니다.
  3. 개인 정보를 입력합니다.
  4. 피드백 보내기를 선택합니다.

시각적 리뷰를 실제로 보려면 시각적 리뷰 보기를 참조하세요.

시각적 리뷰를 위한 리뷰 앱 구성

피드백 양식은 리뷰 앱의 페이지에 추가하는 스크립트를 통해 제공됩니다. 이는 응용 프로그램의 <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_IIDrules: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를 입력하도록 요구합니다.

시각적 리뷰용 인증

개인 및 내부 프로젝트에서 시각적 리뷰를 활성화하려면 data-require-auth 변수true로 설정하세요. 활성화된 경우, 사용자는 피드백을 제출하기 전에 api 범위를 갖는 개인 액세스 토큰을 입력해야 합니다.

이와 같은 방법은 모든 공개 프로젝트에 대해 인증을 요구하는 데 사용할 수 있습니다.