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

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

start-review-app-pipeline 작업

다음 시나리오 중 어느 것이든, start-review-app-pipeline 작업은 자동으로 시작됩니다(병합 요청이 승인될 때만):

  • CI 구성 변경이 있는 병합 요청
  • 프론트엔드 변경이 있는 병합 요청
  • {,ee/,jh/}{app/controllers}/**/*에 변경이 있는 병합 요청
  • {,ee/,jh/}{app/models}/**/*에 변경이 있는 병합 요청
  • {,ee/,jh/}lib/{,ee/,jh/}gitlab/**/*에 변경이 있는 병합 요청
  • QA 변경이 있는 병합 요청
  • 스케줄된 파이프라인
  • MR에 pipeline:run-review-app 레이블이 설정됨

리뷰 앱에서 E2E 테스트 실행

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

qa 단계는 다음 작업으로 구성됩니다:

  • review-qa-smoke: GitLab의 핵심 기능을 검증하기 위한 작고 빠른 테스트 하위 집합입니다.
  • review-qa-blocking: 병합 요청을 차단하는 테스트의 하위 집합입니다. 이러한 테스트는 안정적으로 간주되며 실패할 수 없습니다.
  • review-qa-non-blocking: 수동으로 트리거할 수 있는 나머지 E2E 테스트입니다.

review-qa-* 작업은 병합 요청의 변경 사항에 대한 엔드 투 엔드 테스트가 라이브 환경에서 통과하는지 확인합니다. 이는 E2E 실패 식별을 프로덕션 경로의 환경이 아닌 병합 요청으로 전환하여 GitLab.com 또는 비용이 많이 드는 GitLab.com 배포 차단기에서 기능이 깨지는 것을 방지합니다. 필요할 경우, review-qa-* 실패는 오류의 근본 원인을 파악하는 데 도움을 주기 위해 SET(소프트웨어 엔지니어 인 테스트) 담당자와 함께 조사해야 합니다.

엔드 투 엔드 테스트 실행이 완료된 후, Allure 보고서가 생성되어 e2e-test-report 작업에 의해 게시됩니다. 보고서에 대한 링크가 포함된 댓글이 병합 요청에 추가됩니다.

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

깨진 master 수정을 병합하기 위해 실패한 리뷰 앱 배포 무시

유지 관리자는 고객 중요 이후 병합 요청이 리뷰 앱 배포 실패로 인해 파이프라인 실패로 차단되는 경우, 깨진 master 동안 병합하는 절차를 사용할 수 있습니다.

성능 메트릭

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라는 이름의 1Password 로그인 항목에서 찾을 수 있습니다.

내 리뷰 앱에 대한 기능 플래그 활성화

  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. “관리된 포드” 섹션에서 포드를 선택합니다. 예를 들어, 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를 내 포드의 이름으로 교체합니다.

포드의 로그 살펴보기

  1. 먼저 클러스터에 접근할 수 있는지 확인하고 container.pods.getLogs 권한을 부여받습니다.

  2. 검토 앱 슬러그로 워크로드 필터링하기. 예를 들어, review-qa-raise-e-12chm0.

  3. migrations 배포를 찾아 엽니다. 예를 들어, review-qa-raise-e-12chm0-migrations.1.

  4. “관리되는 포드” 섹션에서 포드를 선택합니다. 예를 들어, review-qa-raise-e-12chm0-migrations.1-nqwtx.

  5. 컨테이너 로그를 선택합니다.

추가적으로, 로그 탐색기를 사용하여 로그를 검색할 수 있습니다. 포드 이름에 대한 예제 쿼리는 다음과 같습니다:

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 파이프라인에서 생성된 Cloud<br/>Native 이미지를 사용하여 검토 앱을 배포합니다.<br><br>Cloud Native 이미지는 GCP `gitlab-review-apps`<br>Kubernetes (GKE) 클러스터의 `review-apps`에 배포됩니다."]; 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 상위 파이프라인" A B1 end subgraph "2. gitlab-org/gitlab 하위 파이프라인" B C E end subgraph "CNG-mirror 파이프라인" D>Cloud Native 이미지가 빌드됩니다]; 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 파이프라인은 각 구성 요소의 Docker 이미지를 생성하며 (예: gitlab-rails-ee, gitlab-shell, gitaly 등) GitLab 파이프라인의 커밋을 기준으로 하여 이를 레지스트리 안에 저장합니다.

    • 우리는 CNG-mirror 프로젝트를 사용하여 Cloud Native GitLab 프로젝트의 레지스트리가 많은 과도한 Docker 이미지로 넘치지 않도록 합니다.

  3. review-build-cng가 완료되면, review-deploy 작업이 공식 GitLab Helm 차트를 사용하여 GCP의 review-apps Kubernetes 클러스터에 리뷰 앱을 배포합니다.

    • 리뷰 앱을 배포하는 데 사용되는 실제 스크립트는 scripts/review_apps/review-apps.sh에서 찾을 수 있습니다.

    • 이 스크립트는 기본 CNG 이미지를 CNG-mirror 프로젝트의 레지스트리에 배포된 이미지로 오버라이드한 우리의 공식 Auto DevOps 스크립트입니다.

    • 우리는 공식 GitLab Helm 차트를 사용하고 있기 때문에, 이는 프로덕션에서 어떻게 보일지에 매우 가까운 전용 환경을 제공받는 것을 의미합니다.

    • 각 리뷰 앱은 자신의 Kubernetes 네임스페이스에 배포됩니다. 이 네임스페이스는 각 브랜치에 대해 유일한 리뷰 앱 슬러그를 기반으로 합니다.

  4. review-deploy 작업이 성공적으로 완료되면, MR 위젯에서 해당 링크를 통해 리뷰 앱을 사용할 수 있어야 합니다. 리뷰 앱에 로그인하려면 아래의 “내 리뷰 앱에 로그인?”을 참조하세요.

추가 메모:

  • 만약 review-deploy 작업이 계속 실패한다면 (수동 재시도이 도움이 되지 않는 경우), #g_qe_engineering_productivity 채널에 메시지를 게시하거나 ~"Engineering Productivity" ~"ep::review apps" ~"type::bug" 문제를 생성하고 머지 요청에 대한 링크를 포함하십시오. 배포 실패는 귀하의 머지 요청에서 도입된 실제 문제를 드러낼 수 있습니다 (즉, 이는 반드시 과도한 실패가 아닐 수도 있습니다)!

  • 만약 review-qa-smoke 작업이 계속 실패한다면 (우리는 이미 그것들을 한 번 재시도 했습니다), 작업의 로그를 확인하십시오: 귀하는 귀하의 머지 요청에서 도입된 실제 문제를 발견할 수 있습니다. 또한 실패가 발생한 시점에 페이지의 스크린샷을 보기 위해 아티팩트를 다운로드할 수 있습니다. 실패의 원인을 찾지 못하거나 변경 사항과 관련이 없는 것 같으면 #test-platform 채널에 메시지를 게시하거나 머지 요청에 대한 링크를 포함한 ~Quality ~"type::bug" 문제를 생성하십시오.

  • 수동으로 review-stop을 사용하여 리뷰 앱을 중지할 수 있으며, GitLab이 머지 요청의 브랜치가 병합된 후 삭제될 때도 시작됩니다.

  • Kubernetes 클러스터는 GitLab Kubernetes 통합을 사용하여 gitlab 프로젝트에 연결되어 있습니다. 이는 기본적으로 머지 요청 위젯에서 직접 리뷰 앱에 링크를 제공할 수 있게 합니다.

리뷰 앱의 자동 중지

리뷰 앱은 마지막 배포 후 2일이 지나면 자동으로 중지됩니다.

환경 자동 중지 기능 덕분입니다.

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

예정된 파이프라인에서 자동으로 실행되는 review-cleanup 작업은 5일 후에 오래된 리뷰 앱을 중지하고, 6일 후에 그 환경을 삭제하며, 7일 후에는 대기 중인 Helm 릴리스 및 Kubernetes 리소스를 정리합니다.

클러스터 구성

클러스터는 engineering-productivity-infrastructure 프로젝트의 Terraform을 통해 구성됩니다.

노드 풀 이미지 유형은 Container-Optimized OS (cos) 여야 하며, Container-Optimized OS with Containerd (cos_containerd)는 이 GitLab Runner의 Kubernetes 실행자에 대한 알려진 문제로 인해 사용하면 안 됩니다.

Helm

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

불건전한 리뷰 앱 릴리스 진단

리뷰 앱 안정성이 감소하면 이는 review-apps 클러스터가 불건전하다는 신호일 수 있습니다.

주요 지표는 재시작으로 이어지는 상태 확인 실패 또는 리뷰 앱 배포의 다수 실패일 수 있습니다.

리뷰 앱 개요 대시보드는 클러스터의 부하 스파이크를 식별하는 데 도움을 주며, 노드가 문제를 일으키고 있거나 전체 클러스터가 불건전한 방향으로 향하고 있는지를 파악하는 데 도움이 됩니다.

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

자주 묻는 질문

매 시험 실행마다 CNG 이미지 빌드를 트리거하는 것이 너무 과한 것이 아닙니까? 이로 인해 수천 개의 사용되지 않는 Docker 이미지가 생성됩니다.

우리는 어디서부터 시작해야 하며 나중에 개선할 수 있습니다. 또한, 우리는 이러한 Docker 이미지를 저장하기 위해 CNG-mirror 프로젝트를 사용하고 있으며, 나중에 레지스트리를 날려버리고 새롭고 비어 있는 레지스트리를 사용할 수 있습니다.

이로 인한 남용을 어떻게 방지합니까? 앱이 세상에 열려 있으므로 우리만 사용하도록 제한할 방법을 찾아야 합니다.

이는 포크에 대해 활성화되어 있지 않습니다.

기타 자료

유용한 커맨드라인 도구

  • K9s - CLI 대시보드를 통해 포드를 관리하고 라벨로 필터링 가능
  • Stern - 라벨/필드 선택기를 기반으로 한 크로스 포드 로그 테일링 가능

테스트 문서로 돌아가기