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 단계 이후에 나오는) review-qa-smoke와 review-qa-blocking 작업이 자동으로 시작됩니다.

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

  • review-qa-smoke: GitLab의 코어 기능을 유효성 검사하기 위한 소규모 및 빠른 테스트입니다.
  • review-qa-blocking: 신뢰할 수 있는 테스트의 하위 집합입니다. 이러한 테스트는 안정적으로 간주되며 실패해서는 안 됩니다.
  • review-qa-non-blocking: 수동으로 트리거할 수 있는 나머지 e2e 테스트입니다.

review-qa-* 작업은 Merge Request의 변경 사항에 대한 E2E 테스트가 실제 환경에서 통과하는지 확인합니다. 이를 통해 E2E 실패를 프로덕션 환경으로의 이동이 아닌 Merge Request으로 이동시켜 GitLab.com의 기능을 막거나 GitLab.com 배포를 비용 증가시키는 블로킹을 방지합니다. 필요한 경우, SET(소프트웨어 엔지니어 인 테스트) 동료와 함께 review-qa-* 실패를 조사하여 오류의 근본 원인을 찾도록 해야 합니다.

E2E 테스트 실행이 완료되면, Allure 보고서가 e2e-test-report 작업에 의해 생성되고 게시됩니다. 해당 Merge Request에 보고서 링크가 포함된 코멘트가 추가됩니다.

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

실패한 리뷰 앱 배포를 우회하여 깨진 master 수정을 Merge하기

유지 보수자는 고객 중요 Merge Request이 리뷰 앱 배포 실패로 인해 파이프라인이 차단된 경우, 깨진 master Merge 프로세스를 사용할 수 있습니다.

성능 메트릭

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

리뷰 앱용 샘플 데이터

리뷰 앱을 배포하면 sample-gitlab-project 템플릿 프로젝트에서 프로젝트 데이터가 생성됩니다. 이는 매뉴얼 및 탐색적 테스트를 용이하게 하기 위해 미리 채워진 리소스가 있는 프로젝트를 제공합니다.

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

사용 방법

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

리뷰 앱을 재설정하고 깨끗한 상태에서 다시 배포하려면 다음을 수행하세요:

  1. review-stop 작업 실행.
  2. review-deploy 작업 실행 또는 다시 시도.

이를 수행하면 이전에 배포된 리뷰 앱의 모든 기존 데이터가 제거됩니다.

GCP 리뷰 앱 클러스터 액세스

gcp-review-apps-dev GCP 그룹 및 역할에 대한 액세스 요청(내부 링크)를 오픈해야 합니다.

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

내 리뷰 앱에 로그인하기

GitLab 팀 멤버만 가능합니다. 리뷰 앱에 로그인하려면 공유된 1Password 계정에 대한 GitLab 핸드북 정보를 확인하세요.

  • 기본 사용자 이름은 root입니다.
  • 패스워드는 GitLab EE Review App이라는 이름으로 된 1Password 로그인 항목에서 찾을 수 있습니다.

내 리뷰 앱용 피처 플래그 활성화하기

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

내 리뷰 앱 슬러그 찾기

  1. review-deploy 작업을 엽니다.
  2. ** Deploying review-*를 찾으세요.
  3. 예를 들어 ** Deploying review-1234-abc-defg... **의 경우, 해당 리뷰 앱 슬러그는 이 경우에는 review-1234-abc-defg가 됩니다.

레일스 콘솔 실행

  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. 먼저 GCP 리뷰 앱 클러스터에 액세스하고 container.pods.getLogs 권한을 확인하세요.
  2. 리뷰 앱 슬러그로 Workloads 필터링을(를) 수행하세요. 예: review-qa-raise-e-12chm0.
  3. migrations 배포를 찾고 열어보세요. 예: review-qa-raise-e-12chm0-migrations.1.
  4. “Managed pods” 섹션에서 Pod를 선택하세요. 예: review-qa-raise-e-12chm0-migrations.1-nqwtx.
  5. Container logs를 선택하세요.

또는 로그 탐색기를 사용할 수도 있으며 더 많은 유틸리티를 제공합니다. 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 deploys the review app using the Cloud<br/>Native images built by the CNG-mirror pipeline.<br><br>Cloud Native images are deployed to the `review-apps`<br>Kubernetes (GKE) cluster, in the GCP `gitlab-review-apps` project."]; D[CNG-mirror]; E[review-qa-smoke, review-qa-blocking, review-qa-non-blocking<br><br>gitlab-qa runs the e2e tests against the review app.]; A --> B1 B1 --> B B -.->|triggers a CNG-mirror pipeline| D D -.->|depends on the multi-project pipeline| 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>Cloud Native images are built]; 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 등)의 Docker 이미지를 GitLab 파이프라인의 커밋을 기반으로 빌드하고 해당 이미지를 레지스트리에 저장합니다.
    • 우리는 CNG-mirror 프로젝트를 사용하여 CNG (Cloud Native GitLab) 프로젝트의 레지스트리가 많은 일시적 Docker 이미지로 인해 과부하되지 않도록 합니다.
  3. review-build-cng가 완료되면, review-deploy 작업이 공식 GitLab Helm 차트를 사용하여 리뷰 앱을 GCP의 review-apps Kubernetes 클러스터에 배포합니다.
    • 리뷰 앱을 배포하는 데 사용된 스크립트는 scripts/review_apps/review-apps.sh에서 찾을 수 있습니다.
    • 이러한 스크립트는 기본적으로 공식 Auto DevOps 스크립트이며, 여기서 기본 CNG 이미지는 CNG-mirror 프로젝트 레지스트리에 덮어씌워집니다.
    • 공식 GitLab Helm 차트를 사용하기 때문에 각 브랜치에 대해 대부분 프로덕션과 매우 유사한 전용 환경을 얻을 수 있습니다.
    • 각 리뷰 앱은 고유한 브랜치별로 고유한 Kubernetes 네임스페이스에 배포됩니다. 네임스페이스는 각 브랜치에 고유한 리뷰 앱 슬러그를 기반으로 합니다.
  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 작업이 계속 실패하는 경우(우리는 이미 한 번 재시도했습니다), 작업의 로그를 확인하세요: 도입된 실제 문제를 발견할 수 있습니다. 실패 발생 시점의 페이지 스크린샷을 보려면 아티팩트를 다운로드할 수도 있습니다. 실패 원인을 찾지 못한 경우 또는 변경 내용과 무관한 것으로 보이면, #test-platform 채널에 메시지를 게시하거나 MR에 대한 링크를 포함하여 ~Quality ~"type::bug" 이슈를 생성하세요.
  • 매뉴얼 review-stop은 리뷰 앱을 매뉴얼으로 중지하며, MR 브랜치가 Merge된 후 삭제될 때 GitLab에 의해 자동으로 시작됩니다.
  • Kubernetes 클러스터는 GitLab Kubernetes 통합을 사용하여 gitlab 프로젝트에 연결되어 있습니다. 이를 통해 Merge Request 위젯에서 리뷰 앱에 직접 링크할 수 있습니다.

리뷰 앱 자동 중지

리뷰 앱은 환경 자동 중지 기능 덕분에 마지막 배포 후 2일 후 자동으로 중지됩니다.

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

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

클러스터 구성

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

노드 풀 이미지 유형은 GitLab Runner를 위한 Kubernetes 실행기에서 발생하는 알려진 문제 때문에 Container-Optimized OS (cos)여야 합니다.

Helm

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

건강하지 않은 리뷰 앱 릴리스 진단

리뷰 앱 안정성이 떨어진다면 review-apps 클러스터가 건강하지 않을 수 있습니다. 선행 지표는 리뷰 앱 배포의 건강 검사 실패로 인한 다시 시작이거나, 리뷰 앱 배포의 대다수 실패일 수 있습니다.

리뷰 앱 개요 대시보드는 클러스터의 부하 급증을 식별하는 데 도움을 주며, 노드에 문제가 있는지 또는 전체 클러스터가 건강하지 않은 방향으로 트렌드가 형성되고 있는지를 확인하는 데 도움을 줍니다.

릴리스 앱 문제 해결을 위한 Engineering Productivity Runbook의 리뷰 앱 페이지를 참조하세요.

자주 묻는 질문

테스트 실행마다 CNG 이미지를 빌드하는 것은 너무 많지 않나요? 이렇게 하면 수천 개의 사용되지 않는 Docker 이미지가 생성됩니다.

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

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

이 기능은 포크에 대해 사용되지 않습니다.

기타 리소스

유용한 명령 줄 도구

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

테스트 문서로 돌아가기