• 리뷰 앱에서의 E2E 테스트 실행
  • 실패한 리뷰 앱 배포 우회하여 망가진 ‘master’ 수정의 병합
• 성능 메트릭
• 리뷰 앱용 샘플 데이터
• 방법
  • 깨끗한 상태에서 리뷰 앱 다시 배포하기
  • GCP 리뷰 앱 클러스터 액세스 방법
  • 내 리뷰 앱에 로그인하기
  • 내 리뷰 앱을 위한 기능 플래그 활성화
  • 내 리뷰 앱 슬러그 찾기
  • Rails 콘솔 실행하기
  • Pod의 로그 살펴보기
• 작동 방식은 무엇인가요?
  • CI/CD 아키텍처 다이어그램
  • 상세 설명
  • 리뷰 앱의 자동 중지
• 클러스터 구성
  • Helm
• 비정상적인 리뷰 앱 릴리스 진단
• 자주 묻는 질문
• 기타 리소스
  • 유용한 명령 줄 도구

GitLab의 개발에서 Review App 사용하기

Review App은 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 테스트 실행

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

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

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

review-qa-* 작업은 병합 요청의 변경 사항에 대한 엔드 투 엔드 테스트가 실제 환경에서 통과하는지 확인합니다. 이는 프로덕션으로 향하는 환경에서가 아닌 병합 요청에서 기능이 망가지는 것을 방지하기 위한 것입니다. 필요한 경우, 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 그룹 및 역할에 대한 액세스 요청(내부 링크)를 엽니다.

이는 다음과 같은 권한을 부여합니다:

• Pod 로그 검색. 뷰어 (roles/viewer)에 의해 부여됩니다.
• Rails 콘솔 실행. Kubernetes Engine Developer (roles/container.pods.exec)에 의해 부여됩니다.

내 리뷰 앱에 로그인하기

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. 먼저 GCP 리뷰 앱 클러스터에 액세스하고 container.pods.exec 권한이 있는지 확인하세요.
2. 리뷰 앱 슬러그로 Workload 필터링하세요. 예를 들어 review-qa-raise-e-12chm0.
3. toolbox 배포를 찾아 엽니다. 예를 들어 review-qa-raise-e-12chm0-toolbox.
4. “Managed pods” 섹션에서 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. 리뷰 앱 슬러그로 Workload 필터링하세요. 예를 들어 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. “컨테이너 로그”를 선택하세요.

또는 로그 탐색기를 사용하여 로그를 검색할 수 있습니다. Pod 이름에 대한 예제 쿼리는 다음과 같습니다:

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

작동 방식은 무엇인가요?

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

상세 설명

1. 모든 파이프라인에서 준비 단계 중에 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 파이프라인의 커밋을 기반으로 각 구성 요소(예: gitlab-rails-ee, gitlab-shell, gitaly 등)의 Docker 이미지를 만들고 그것들을 레지스트리에 저장합니다.
   • CNG-mirror 프로젝트를 사용하여 CNG (Cloud Native GitLab) 프로젝트의 레지스트리가 일시적인 Docker 이미지로 지나치게 과부하 받지 않도록 합니다.
3. review-build-cng가 완료되면, review-deploy 작업은 공식 GitLab Helm 차트를 사용하여 GCP의 review-apps 쿠버네티스 클러스터에 리뷰 앱을 배포합니다.
   • 리뷰 앱을 배포하는 데 사용되는 실제 스크립트는 scripts/review_apps/review-apps.sh에서 찾을 수 있습니다.
   • 이러한 스크립트는 기본적으로 공식 Auto DevOps 스크립트로, 여기서는 기본 CNG 이미지를 CNG-mirror 프로젝트의 레지스트리에 빌드하고 저장된 이미지로 덮어씁니다.
   • 공식 GitLab Helm 차트를 사용하므로 브랜치별로 별도의 환경을 제공받을 수 있습니다.
   • 각 리뷰 앱은 고유한 브랜치별 슬러그를 기반으로 한 개별적인 쿠버네티스 네임스페이스에 배포됩니다.
4. review-deploy 작업이 성공하면 MR 위젯에서 해당 리뷰 앱으로의 직접 링크를 통해 리뷰 앱을 사용할 수 있어야 합니다. 리뷰 앱에 로그인하려면 아래 “내 리뷰 앱에 로그인하려면?”을 참조하세요.

추가 사항:

• 만약 review-deploy 작업이 지속적으로 실패한다면(수동 재시도도 도움이 되지 않음) #g_qe_engineering_productivity 채널에 메시지를 게시하거나, ~"Engineering Productivity" ~"ep::review apps" ~"type::bug" 이슈를 만들어 병합 요청의 링크를 첨부하세요. 배포 실패는 병합 요청에서 발생한 실제 문제를 나타낼 수 있습니다(즉, 이것은 일시적인 실패가 아닐 수 있음)!
• 만약 review-qa-smoke 또는 review-qa-reliable 작업이 지속적으로 실패한다면(이미 한 번 재시도), 작업 로그를 확인하세요: 병합 요청에서 실제 문제가 발생했을 수 있습니다. 또한 실패 발생 시점의 페이지 스크린샷을 보기 위해 아티팩트를 다운로드할 수도 있습니다. 실패의 원인을 찾지 못하거나 변경 사항과 관련이 없는 것으로 보인다면, #test-platform 채널에 메시지를 게시하거나, ~Quality ~"type::bug" 이슈를 만들어 병합 요청의 링크를 첨부하세요.
• 수동 review-stop은 리뷰 앱을 수동으로 중지할 수 있으며, 병합 요청 브랜치가 병합된 후 삭제될 때 GitLab에서도 시작됩니다.
• 쿠버네티스 클러스터는 GitLab 쿠버네티스 통합을 사용하여 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 버전은 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 프로젝트를 사용하여 언제든지 레지스트리를 지울 수 있고 새롭고 비어있는 것을 사용할 수 있습니다.

이것을 남용으로부터 어떻게 보호합니까? 앱은 세계에 공개되어 있기 때문에 우리만으로 제한하는 방법을 찾아야 합니다.

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

기타 리소스

• CE/EE용 리뷰 앱 통합 (발표)
• 안정성 문제

유용한 명령 줄 도구

• K9s - 포드 전체에서 CLI 대시보드 및 레이블로 필터링 가능
• Stern - 레이블/필드 선택기를 기반으로 한 포드 전체 로그 테일링 기능

테스트 설명서로 돌아가기