• 리뷰 앱 작동 방식
• 리뷰 앱 구성
  • 리뷰 앱 버튼 사용
• 리뷰 앱 자동 중지
• 리뷰 앱 예시
• 라우트 맵
  • 경로 맵 예시

리뷰 앱

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

리뷰 앱:

• 특징 브랜치에서의 변경 사항에 대한 자동 라이브 미리보기를 제공하여 Merge Request을 위한 동적 환경을 구축합니다.
• 디자이너 및 제품 관리자가 귀하의 변경 사항을 확인하고 브랜치를 체크아웃하고 런타임 환경에서 변경 사항을 실행하지 않아도 변경 사항을 볼 수 있습니다.
• GitLab DevOps LifeCycle과 완벽하게 통합됩니다.
• 변경 사항을 원하는 곳에 배포할 수 있습니다.

이전 예시에서:

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

리뷰 앱 작동 방식

리뷰 앱은 환경과의 매핑입니다. 리뷰 앱에 대한 액세스는 브랜치와 관련된 Merge Request의 링크로 제공됩니다.

다음은 동적으로 설정된 리뷰 앱이 있는 Merge Request의 예시입니다.

이 예시에서 브랜치는 다음과 같이:

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

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

1. 브랜치를 푸시하고 실행 환경 작업의 script 정의를 기반으로 리뷰 앱을 실행합니다.
2. 빌드 및 웹 응용 프로그램 배포를 실행 환경에서 기다립니다.
3. 변경 사항을 실시간으로 보려면 브랜치에 관련된 Merge Request의 링크를 선택합니다.

리뷰 앱 구성

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

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

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

리뷰 앱 버튼 사용

프로젝트에서 리뷰 앱을 구성할 때 상기한 대로 .gitlab-ci.yml 파일에 새 작업을 추가합니다. 이를 간단하게 만들기 위해 쿠버네티스를 사용하면 리뷰 앱 활성화를 선택하면 GitLab은 프로젝트에 대한 템플릿 코드 블록을 제공합니다. 이를 .gitlab-ci.yml로 복사하여 붙여넣을 수 있습니다.

사전 요구 사항:

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

리뷰 앱 템플릿 사용 방법:

1. 좌측 사이드바에서 검색 또는 이동을 선택하고 리뷰 앱 작업을 생성하려는 프로젝트를 찾습니다.
2. 운영 > 환경을 선택합니다.
3. 리뷰 앱 활성화를 선택합니다.
4. 대화 상자 안의 지침을 따릅니다. 필요에 따라 제공된 .gitlab-ci.yml 템플릿을 편집할 수 있습니다.

리뷰 앱 자동 중지

특정 기간 이후에 리뷰 앱 환경을 만료 및 자동 중지하도록 구성하는 방법을 확인하세요.

리뷰 앱 예시

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

리뷰 앱의 다른 예시:

• GitLab의 클라우드 네이티브 개발.
• Android용 리뷰 앱.

라우트 맵

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

설정한 후에는 Merge Request 위젯에서 리뷰 앱 링크를 선택하여 페이지 변경 사항으로 바로 이동할 수 있으므로 제안된 수정 사항을 더 쉽고 빠르게 미리 볼 수 있습니다.

라우트 맵을 구성하면 깃랩에게 리포지터리의 파일 경로가 웹사이트의 페이지 경로와 어떻게 매핑되는지 알려주는 YAML 배열이 포함된 .gitlab/route-map.yml 내부에 파일을 추가합니다. 라우트 맵을 구성하면 보기 버튼이 표시됩니다. Merge Request에서 변경된 페이지로 바로 이동하려면 이 버튼을 선택하세요.

라우트 맵을 설정하려면 리포지터리 내부에 .gitlab/route-map.yml 파일을 추가하고, 이 파일에는 source 경로(리포지터리 내부)를 public 경로(웹사이트에서)에 매핑하는 YAML 배열이 있어야 합니다.

경로 맵 예시

다음은 Middleman에 대한 경로 맵의 예입니다. 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 표현식을 찾아 일치시키고, 필요한 경우 () 캡처 그룹의 값을 사용하여 \N 표현식을 대체해서 결정됩니다.

위의 예시에서 매핑이 정의된 순서에 따라 매핑이 평가되는 사실을 활용하여 source/index.html.haml이 /source\/(.+?\.html).*/ 대신에 /source\/(.*)/와 일치하여 index.html로 공개 경로가 생성되는 것을 보여줍니다.

경로 맵을 설정한 후 해당 효과는 다음 위치에서 나타납니다.

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

  • 디렉터리은 경로 맵에서 첫 5개의 일치 항목을 표시하지만, 5개 이상 사용 가능한 경우에는 필터링할 수 있습니다.

    

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

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