GitLab 개발에서 리뷰 앱 사용하기

리뷰 앱은 start-review-app-pipeline 작업을 사용하여 배포되며, 리뷰 앱을 배포하는 데 필요한 여러 작업을 수행하는 일련의 작업을 포함하는 자식 파이프라인을 트리거합니다.

start-review-app-pipeline job

다음 시나리오 중 하나에 해당하는 경우 start-review-app-pipeline 작업이 자동으로 시작됩니다(Merge Request이 승인된 경우에만):

  • CI 구성 변경이 있는 Merge Request의 경우
  • 프론트엔드 변경이 있는 Merge Request의 경우
  • {,ee/,jh/}{app/controllers}/**/*에 변경 내용이 있는 Merge Request의 경우
  • {,ee/,jh/}{app/models}/**/*에 변경 내용이 있는 Merge Request의 경우
  • {,ee/,jh/}lib/{,ee/,jh/}gitlab/**/*에 변경 내용이 있는 Merge Request의 경우
  • QA 변경이 있는 Merge Request의 경우
  • 예약된 파이프라인의 경우
  • MR에 pipeline:run-review-app 라벨이 설정된 경우

리뷰 앱에서의 E2E 테스트 실행

qa 단계의 모든 파이프라인에서 review-qa-smoke와 review-qa-blocking 작업이 자동으로 시작됩니다.

qa 단계에는 다음과 같은 작업이 포함됩니다:

  • review-qa-smoke: GitLab의 핵심 기능을 검증하기 위한 소규모이면서 빠른 테스트의 서브셋
  • review-qa-blocking: 신뢰할 수 있는 테스트의 서브셋. 이러한 테스트는 안정적으로 간주되며 실패할 수 없습니다.
  • review-qa-non-blocking: 수동으로 트리거할 수 있는 나머지 e2e 테스트

review-qa-* 작업은 Merge Request의 변경 사항에 대한 end-to-end 테스트가 실시 환경에서 통과되도록 보장합니다. 이는 e2e 실패를 프로덕션 경로 환경이 아닌 Merge Request으로 이동시켜 GitLab.com의 기능을 파괴하거나 비용 소모적인 GitLab.com 배포 블로커를 방지합니다. 필요한 경우, review-qa-* 실패는 SET(테스트 소프트웨어 엔지니어) 동료와 함께 오류의 근본 원인을 확인하는 데 도움을 줍니다.

end-to-end 테스트 실행이 완료되면 Allure 보고서가 생성되고 e2e-test-report 작업에 의해 게시됩니다. 보고서에 대한 링크가 Merge Request에 추가됩니다.

오류는 gitlab-review-apps Sentry 프로젝트에서 찾을 수 있으며, 검토 앱 URL로 필터링하거나 커밋 SHA로 필터링할 수 있습니다.

실패한 리뷰 앱 배포 우회하여 손상된 master 수정 Merge

관리자는 리뷰 앱 배포 실패로 인해 파이프라인이 차단되어 고객 중요 Merge Request이 차단된 경우 손상된 master Merge 프로세스를 사용할 수 있습니다.

성능 지표

qa 단계의 모든 리뷰 앱 자식 파이프라인에서 browser_performance 작업이 자동으로 시작됩니다: 이 작업은 Sitespeed.io Container를 사용하여 기본 브라우저 성능 테스트를 수행합니다.

리뷰 앱용 샘플 데이터

리뷰 앱 배포 후, 프로젝트 데이터가 sample-gitlab-project 템플릿 프로젝트에서 생성됩니다. 이는 매뉴얼 및 탐색적 테스트를 용이하게 하기 위해 프로젝트에 사전으로 채워진 리소스를 제공하기 위한 것입니다.

샘플 프로젝트는 root 사용자 네임스페이스에 생성되며 해당 사용자의 개인 프로젝트 디렉터리에서 확인할 수 있습니다.

방법

깨끗한 상태에서 리뷰 앱 재배포

리뷰 앱을 초기화하고 깨끗한 상태에서 재배포하려면 다음을 수행하십시오:

  1. review-stop 작업을 실행합니다.
  2. review-deploy 작업을 실행하거나 다시 시도합니다.

이렇게 하면 이전에 배포된 리뷰 앱에서 모든 기존 데이터가 제거됩니다.

GCP 리뷰 앱 클러스터 액세스 방법

gcp-review-apps-dev GCP 그룹 및 역할에 대해 액세스 요청을 엽니다(내부 링크).

이를 통해 다음과 같은 권한을 획들할 수 있습니다:

내 리뷰 앱에 로그인하기

GitLab 팀 구성원 전용입니다. 리뷰 앱에 로그인하려면 공유 1Password 계정에 대한 GitLab 핸드북 정보를 확인하세요.

  • 기본 사용자 이름은 root입니다.
  • 비밀번호는 GitLab EE Review App라는 로그인 항목에서 찾을 수 있습니다.

리뷰 앱에 피처 플래그 활성화

  1. 리뷰 앱을 열고 위에서 문서화한대로 로그인합니다.
  2. 개인 액세스 토큰을 생성합니다.
  3. 피처 플래그 API를 사용하여 피처 플래그를 활성화합니다.

나의 리뷰 앱 슬러그 찾기

  1. review-deploy 작업을 엽니다.
  2. ** Deploying review-*를 찾습니다.
  3. 예를 들어 ** Deploying review-1234-abc-defg... **에 대해 순서상의 리뷰 앱 슬러그는 이 경우에 review-1234-abc-defg입니다.

Rails 콘솔 실행

  1. 먼저 클러스터에 액세스하고 container.pods.exec 권한을 확인하십시오.
  2. 리뷰 앱 슬러그로 작업 부하를 필터링합니다. 예를 들어 review-qa-raise-e-12chm0입니다.
  3. toolbox 배포를 찾아 엽니다. 예를 들어 review-qa-raise-e-12chm0-toolbox입니다.
  4. “관리형 pod” 섹션에서 pod을 선택합니다. 예를 들어 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz입니다.
  5. KUBECTL 드롭다운 디렉터리을 선택한 다음 Exec -> toolbox를 선택합니다.
  6. 기본 명령에서 -c toolbox -- ls를 -it -- gitlab-rails console로 바꾸거나
    • kubectl exec --namespace review-qa-raise-e-12chm0 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz -it -- gitlab-rails console를 실행하고
    • review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz를 해당 pod의 이름으로 교체합니다.

pod 로그 검색

  1. 먼저 클러스터에 액세스하고 container.pods.getLogs 권한을 확인하십시오.
  2. 리뷰 앱 슬러그로 작업 부하를 필터링합니다. 예를 들어 review-qa-raise-e-12chm0입니다.
  3. migrations 배포를 찾아 엽니다. 예를 들어 review-qa-raise-e-12chm0-migrations.1입니다.
  4. “관리형 pod” 섹션에서 pod을 선택합니다. 예를 들어 review-qa-raise-e-12chm0-migrations.1-nqwtx입니다.
  5. 컨테이너 로그를 선택합니다.

또한 더욱 많은 유틸리티를 제공하는 로그 익스플로러를 사용할 수도 있습니다. pod 이름에 대한 예시 쿼리는 다음과 같습니다: 

resource.labels.pod_name:"review-qa-raise-e-12chm0-migrations"

작동 방식

CI/CD 아키텍처 다이어그램

graph TD A["build-qa-image, compile-production-assets<br/>(canonical default refs only)"]; B1[start-review-app-pipeline]; B[review-build-cng]; C["review-deploy<br><br>Helm은 CNG-mirror 파이프라인에서 빌드된 클라우드 네이티브 이미지를 사용하여 리뷰 앱을 배포합니다.<br><br>클라우드 네이티브 이미지는 GCP `gitlab-review-apps` 프로젝트에 있는 `review-apps`<br>쿠버네티스(GKE) 클러스터에 배포됩니다."]; D[CNG-mirror]; E[review-qa-smoke, review-qa-blocking, review-qa-non-blocking<br><br>gitlab-qa는 리뷰 앱에 대한 e2e 테스트를 실행합니다.]; A --> B1 B1 --> B B -.->|CNG-mirror 파이프라인을 트리거합니다| D D -.->|다중 프로젝트 파이프라인에 종속됩니다| B B --> C C --> E subgraph "1. gitlab-org/gitlab parent pipeline" A B1 end subgraph "2. gitlab-org/gitlab child pipeline" B C E end subgraph "CNG-mirror pipeline" D>클라우드 네이티브 이미지가 빌드됩니다]; end

상세한 설명

  1. 모든 파이프라인은 prepare 단계에서 자동으로 compile-production-assets 작업이 시작됩니다.
    • 이 작업이 완료되면, review-build-cng 작업이 시작됩니다. 왜냐하면 다음 단계에서 트리거된 CNG-mirror 파이프라인이 이 작업에 종속되기 때문입니다.
  2. compile-production-assets 작업이 완료되면, review-build-cng 작업이 CNG-mirror 프로젝트의 파이프라인을 트리거합니다.
    • review-build-cng 작업은 MR에 CI 또는 프론트엔드 변경 사항이 포함된 경우에만 자동으로 시작됩니다. 다른 경우에는 매뉴얼으로 시작됩니다.
    • CNG-mirror 파이프라인은 각 컴포넌트 (예: gitlab-rails-ee, gitlab-shell, gitaly 등)의 도커 이미지를 GitLab 파이프라인의 커밋을 기반으로 만들고 자체 레지스트리에 저장합니다.
    • 우리는 CNG-mirror 프로젝트를 사용하여 CNG (Cloud Native GitLab) 프로젝트의 레지스트리가 많은 일시적인 도커 이미지로 오버로드되지 않도록 합니다.
  3. review-build-cng 작업이 완료되면, review-deploy 작업이 공식 GitLab Helm 차트를 사용하여 GCP의 review-apps 쿠버네티스 클러스터로 리뷰 앱을 배포합니다.
  4. review-deploy 작업이 성공하면 MR 위젯에서 해당 리뷰 앱에 대한 직접 링크를 통해 리뷰 앱을 사용할 수 있습니다. 리뷰 앱에 로그인하려면 아래의 “리뷰 앱에 로그인하려면?”을 참조하세요.

추가 참고사항:

  • review-deploy 작업이 계속 실패하는 경우 (매뉴얼 재시도가 도움이 되지 않았을 경우), #g_qe_engineering_productivity 채널에 메시지를 게시하거나 ~"Engineering Productivity" ~"ep::review apps" ~"type::bug" 이슈를 만들어 MR 링크를 첨부하세요. 배포 실패는 MR에 도입된 실제 문제를 보여줄 수 있습니다 (즉, 이것은 일시적인 실패일 필요는 없음)!
  • review-qa-smoke 또는 review-qa-reliable 작업이 계속 실패하는 경우 (이미 한 번 재시도했음), 작업 로그를 확인하세요. MR에 도입된 실제 문제를 발견할 수 있습니다. 실패 발생 시점의 페이지 스크린샷을 확인할 수 있는 아티팩트를 다운로드할 수도 있습니다. 실패 원인을 찾지 못하거나 변경과 무관한 것으로 보이면, #test-platform 채널에 메시지를 게시하거나 MR에 대한 ~Quality ~"type::bug" 이슈를 생성하세요.
  • 매뉴얼 review-stop은 리뷰 앱을 매뉴얼으로 중지하는 데 사용될 수 있으며, MR 브랜치가 Merge된 후 삭제되면 GitLab에 의해 자동으로 시작됩니다.
  • 쿠버네티스 클러스터는 GitLab Kubernetes 통합을 사용하여 gitlab 프로젝트에 연결됩니다. 이를 통해 MR 위젯에서 리뷰 앱으로 직접 링크가 가능합니다.

리뷰 앱의 자동 중지

리뷰 앱은 마지막 배포 후 2일 후에 자동으로 중지되며, 환경 자동 중지 기능을 이용합니다.

리뷰 앱을 더 오래 유지해야 하는 경우, 해당 환경을 고정하거나 review-deploy 작업을 다시 시도하여 “최근 배포 시간”을 업데이트할 수 있습니다.

스케줄된 파이프라인에서 자동으로 실행되는 review-cleanup 작업은 5일 후에 사용되지 않는 리뷰 앱을 중지하고, 6일 후에 해당 환경을 삭제하며, 남아있는 Helm 릴리스와 쿠버네티스 리소스를 정리합니다.

클러스터 구성

클러스터는 engineering-productivity-infrastructure 프로젝트에서 Terraform을 사용하여 구성됩니다.

노드 풀 이미지 유형은 Container-Optimized OS (cos)여야 하며, Container-Optimized OS with Containerd (cos_containerd)가 아니어야 합니다. 이는 GitLab Runner를 위한 Kubernetes executor의 알려진 이슈 때문입니다.

Helm

사용된 Helm 버전은 review-deploy 및 review-stop 작업에서 사용되는 registry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-helm3.5-kubectl1.17 이미지에서 정의됩니다.

이상한 리뷰 앱 릴리스 진단

리뷰 앱 안정성이 저하되면, review-apps 클러스터가 건강하지 않을 수 있음을 나타낼 수 있습니다. 주요 지표는 다시 시작으로 이어지는 상태 체크 실패 또는 리뷰 앱 배포의 대다수 실패일 수 있습니다.

리뷰 앱 개요 대시보드는 클러스터에서의 부하 급등, 노드의 문제 또는 전체 클러스터의 불건전한 흐름을 식별하는 데 도움이 됩니다.

리뷰 앱 릴리스에 대한 문제 해결을 위해 공학 프로덕션성 런북의 리뷰 앱 페이지를 참조하세요.

자주 묻는 질문

매 테스트 실행마다 CNG 이미지 빌드를 트리거하는 것은 너무 많지 않나요? 수천 개의 사용되지 않는 Docker 이미지가 만들어집니다.

어딘가에서 시작해야 하며 나중에 개선해야 합니다. 또한, 이러한 Docker 이미지를 저장하기 위해 CNG-mirror 프로젝트를 사용하여 언젠가 레지스트리를 지울 수 있고 새로운 비어있는 것을 사용할 수 있습니다.

이것을 남용으로부터 어떻게 보호하나요? 앱은 전세계에 공개되어 있으므로 우리만 사용할 수 있도록 제한하는 방법을 찾아야 합니다.

이것은 포크로 활성화되지 않았습니다.

기타 리소스

유용한 명령줄 도구

  • K9s - 레이블 별 CLI 대시보드 및 필터링을 통한 파드를 횡단하는 기능을 제공합니다.
  • Stern - 레이블/필드 선택기를 기반으로 한 파드 간 로그 테일링을 활성화합니다.

테스트 문서로 돌아가기