• 리뷰 앱 작동 원리
• 리뷰 앱 구성
  • 리뷰 앱 활성화 버튼
• 리뷰 앱 자동 중지
• 리뷰 앱 예제
• 경로 맵
  • 라우트 맵 예제

리뷰 앱

리뷰 앱은 제품 변경 사항을 보여주는 환경을 제공하는 협업 도구입니다.

리뷰 앱:

• 기능 브랜치에서 발생한 변경 사항의 자동 라이브 미리보기를 제공하여 병합 요청을 위해 동적 환경을 생성합니다.
• 디자이너와 제품 관리자가 브랜치를 확인하고 샌드박스 환경에서 변경 사항을 실행하지 않고도 변경 사항을 볼 수 있도록 합니다.
• GitLab DevOps 라이프사이클과 완전히 통합되어 있습니다.
• 원하는 곳에 변경 사항을 배포할 수 있습니다.

이전 예제에서:

• topic branch에 커밋이 푸시될 때마다 리뷰 앱이 생성됩니다.
• 리뷰어는 세 번의 리뷰 중 두 번 실패한 후 세 번째 리뷰를 통과합니다.
• 리뷰가 통과한 후 topic branch가 기본 브랜치에 병합되고, 그곳에서 스테이징에 배포됩니다.
• 스테이징에서 승인을 받은 후 기본 브랜치에 병합된 변경 사항이 프로덕션에 배포됩니다.

리뷰 앱 작동 원리

리뷰 앱은 환경과 브랜치의 매핑입니다.
리뷰 앱에 대한 접근은 해당 브랜치와 관련된 병합 요청에 링크로 제공됩니다.

다음은 동적으로 설정된 환경을 가진 병합 요청의 예입니다.

이 예제에서 브랜치는 다음과 같은 상태였습니다:

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

리뷰 앱을 워크플로우에 추가한 후에는 브랜칭된 Git 흐름을 따릅니다. 즉:

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

리뷰 앱 구성

리뷰 앱은 각 브랜치에 대해 동적으로 새로운 환경을 생성할 수 있는 동적 환경 위에 구축됩니다.

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

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

리뷰 앱 활성화 버튼

프로젝트에 대해 리뷰 앱을 구성할 때, 위에서 언급한 대로 .gitlab-ci.yml 파일에 새 작업을 추가합니다.
이를 용이하게 하기 위해 Kubernetes를 사용하는 경우 Enable review apps를 선택하면 GitLab이 복사해서 붙여넣을 수 있는 템플릿 코드 블록을 표시합니다.

선행 조건:

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

리뷰 앱 템플릿을 사용하려면:

1. 왼쪽 사이드바에서 Search or go to를 선택하고
   리뷰 앱 작업을 생성할 프로젝트를 찾습니다.
2. Operate > Environments를 선택합니다.
3. Enable review apps를 선택합니다.
4. 대화 상자의 지침을 따릅니다.
   필요한 경우 제공된 .gitlab-ci.yml 템플릿을 수정할 수 있습니다.

리뷰 앱 자동 중지

주어진 시간 동안 리뷰 앱 환경을 만료하고 자동으로 중지하는 방법을 확인하세요.

리뷰 앱 예제

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

리뷰 앱의 추가 예제:

• GitLab로 클라우드 네이티브 개발.
• Android용 리뷰 앱을 확인하세요.

경로 맵

경로 맵을 사용하면 소스 파일에서 리뷰 앱을 위해 정의된 환경의 공개 페이지로 직접 이동할 수 있습니다.

구성이 완료되면, 병합 요청 위젯의 리뷰 앱 링크가 변경된 페이지로 직접 이동할 수 있어 제안된 수정을 미리보기가 더욱 쉽고 빠릅니다.

경로 맵 구성을 위해 GitLab에 리포지토리의 파일 경로가 웹사이트의 페이지 경로와 어떻게 매핑되는지를 알려줍니다.

경로 맵을 구성하면 View on 버튼이 표시됩니다.

이 버튼을 선택하여 병합 요청에서 변경된 페이지로 직접 이동할 수 있습니다.

경로 맵을 설정하려면, 리포지토리 내에 .gitlab/route-map.yml 파일을 추가하십시오.

이 파일은 source 경로(리포지토리 내)와 public 경로(웹사이트) 간의 매핑을 포함하는 YAML 배열을 포함해야 합니다.

라우트 맵 예제

다음은 Middleman용 라우트 맵의 예입니다.

정적 사이트 생성기(SSG)로서 GitLab 웹사이트를 구축하는 데 사용되며, 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 경로에서 참조할 수 있습니다.
    • 슬래시(/)는 이스케이프할 수 있지만(\/), 할 필요는 없습니다.
    • 리터럴 점(.)은 \.로 이스케이프해야 합니다.
• public, '로 시작하고 끝나는 문자열입니다.
  • \N 표현식을 포함할 수 있어, source 정규 표현식에서 발생 순서에 따라 캡처 그룹을 참조할 수 있습니다(시작은 \1부터).

소스 경로에 대한 공개 경로는 이를 일치시키는 첫 번째 source 표현식을 찾아서 결정되며, 해당하는 public 경로를 반환하고, 적절한 경우 \N 표현식을 () 캡처 그룹의 값으로 교체합니다.

위의 예에서 맵핑이 정의된 순서대로 평가된다는 사실을 사용하여 source/index.html.haml이 /source\/(.+?\.html).*/와 일치하고 index.html의 공개 경로를 얻는 대신 /source\/(.*)/에 대해 일치하게 됩니다.

라우트 맵을 설정한 후, 다음 위치에서 효과를 발휘합니다:

• 머지 요청 위젯에서:
  • 앱 보기 버튼은 .gitlab-ci.yml 파일에 설정된 환경 URL로 이동합니다.

  • 목록은 라우트 맵에서 처음 5개의 일치 항목을 보여주지만, 5개 이상의 항목이 있는 경우 필터링할 수 있습니다.

    

• 비교 또는 커밋의 차이에서, 파일 옆의 보기 ()를 선택하여.

• 블롭 파일 보기에서, 파일 옆의 보기 ()를 선택하여.