리뷰 앱
리뷰 앱은 제품 변경 사항을 쇼케이스할 환경을 제공하는 협업 도구입니다.
리뷰 앱:
- 특징 브랜치에서의 변경 사항에 대한 자동 라이브 미리보기를 제공하여 Merge Request을 위한 동적 환경을 구축합니다.
- 디자이너 및 제품 관리자가 귀하의 변경 사항을 확인하고 브랜치를 체크아웃하고 런타임 환경에서 변경 사항을 실행하지 않아도 변경 사항을 볼 수 있습니다.
- GitLab DevOps LifeCycle과 완벽하게 통합됩니다.
- 변경 사항을 원하는 곳에 배포할 수 있습니다.
이전 예시에서:
- 커밋이 ‘주제 브랜치’에 푸시될 때마다 리뷰 앱이 구축됩니다.
- 리뷰어는 세 번째 리뷰를 통과하기 전에 두 번의 리뷰를 실패합니다.
- 리뷰가 통과되면 ‘주제 브랜치’가 기본 브랜치로 Merge되어 스테이징으로 배포됩니다.
- 스테이징에서 승인되면 기본 브랜치에 Merge된 변경 사항이 프로덕션으로 배포됩니다.
리뷰 앱 작동 방식
리뷰 앱은 환경과의 매핑입니다. 리뷰 앱에 대한 액세스는 브랜치와 관련된 Merge Request의 링크로 제공됩니다.
다음은 동적으로 설정된 리뷰 앱이 있는 Merge Request의 예시입니다.
이 예시에서 브랜치는 다음과 같이:
- 성공적으로 빌드되었습니다.
- 앱 보기를 선택하여 도달할 수 있는 동적 환경에 배포되었습니다.
리뷰 앱을 추가한 후에는 브랜치 Git 플로우를 따릅니다. 즉,
- 브랜치를 푸시하고 실행 환경 작업의
script
정의를 기반으로 리뷰 앱을 실행합니다. - 빌드 및 웹 응용 프로그램 배포를 실행 환경에서 기다립니다.
- 변경 사항을 실시간으로 보려면 브랜치에 관련된 Merge Request의 링크를 선택합니다.
리뷰 앱 구성
리뷰 앱은 동적 환경에 구축되며, 각 브랜치에 대해 동적으로 새 환경을 생성할 수 있도록 합니다.
리뷰 앱 구성 과정은 다음과 같습니다:
- 리뷰 앱을 호스팅하고 배포할 인프라를 설정합니다(아래 예시 확인).
- 배포를 위해 설치 및 구성된 러너를 가져옵니다.
-
.gitlab-ci.yml
에서 미리 정의된 CI/CD 변수인${CI_COMMIT_REF_SLUG}
을 사용하여 동적 환경을 생성하고 브랜치에서만 실행되도록하는 작업을 설정합니다. 또는 프로젝트에서 리뷰 앱을 활성화하여이 작업에 대한 YAML 템플릿을 받을 수 있습니다. - 선택적으로 리뷰 앱을 매뉴얼으로 중지하는 작업을 설정합니다.
리뷰 앱 버튼 사용
프로젝트에서 리뷰 앱을 구성할 때 상기한 대로 .gitlab-ci.yml
파일에 새 작업을 추가합니다. 이를 간단하게 만들기 위해 쿠버네티스를 사용하면 리뷰 앱 활성화를 선택하면 GitLab은 프로젝트에 대한 템플릿 코드 블록을 제공합니다. 이를 .gitlab-ci.yml
로 복사하여 붙여넣을 수 있습니다.
사전 요구 사항:
- 프로젝트에 대한 최소한 개발자 권한이 필요합니다.
리뷰 앱 템플릿 사용 방법:
- 좌측 사이드바에서 검색 또는 이동을 선택하고 리뷰 앱 작업을 생성하려는 프로젝트를 찾습니다.
- 운영 > 환경을 선택합니다.
- 리뷰 앱 활성화를 선택합니다.
- 대화 상자 안의 지침을 따릅니다.
필요에 따라 제공된
.gitlab-ci.yml
템플릿을 편집할 수 있습니다.
리뷰 앱 자동 중지
특정 기간 이후에 리뷰 앱 환경을 만료 및 자동 중지하도록 구성하는 방법을 확인하세요.
리뷰 앱 예시
다음은 리뷰 앱 구성을 보여주는 예시 프로젝트입니다:
리뷰 앱의 다른 예시:
라우트 맵
라우트 맵을 사용하면 소스 파일에서 리뷰 앱에 정의된 환경의 공개 페이지로 직접 이동할 수 있습니다.
설정한 후에는 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
로 공개 경로가 생성되는 것을 보여줍니다.
경로 맵을 설정한 후 해당 효과는 다음 위치에서 나타납니다.