엔드-투-엔드 테스트

요약

엔드-투-엔드(e2e) 테스트는 함께 동작해야 하는 모든 마이크로서비스 및 컴포넌트의 통합을 포함하여, 전체 소프트웨어 스택과 아키텍처에 걸쳐 애플리케이션이 예상대로 동작하는지 확인하기 위한 전략입니다. GitLab을 테스트하기 위해 다음을 수행합니다:

엔드-투-엔드 테스트란 무엇인가요?#

엔드-투-엔드(e2e) 테스트는 함께 동작해야 하는 모든 마이크로서비스 및 컴포넌트의 통합을 포함하여, 전체 소프트웨어 스택과 아키텍처에 걸쳐 애플리케이션이 예상대로 동작하는지 확인하기 위한 전략입니다.

GitLab은 어떻게 테스트하나요?#

GitLab을 테스트하기 위해 다음을 수행합니다:

CNG를 사용하여 GitLab Cloud Native 패키지를 빌드합니다.
orchestrator CLI 도구를 사용하여 이 패키지를 배포하고 E2E 테스트를 실행할 GitLab 인스턴스를 생성합니다.

또한 더 빠른 테스트 피드백을 위해 빠르게 배포할 수 있는 테스트 환경으로 GitLab Development Kit(GDK)를 사용합니다.

나이틀리 빌드 테스트#

매일 밤 스케줄 파이프라인을 실행하여 Omnibus로 생성된 나이틀리 빌드를 테스트합니다. 이 파이프라인은 https://gitlab.com/gitlab-org/gitlab/-/pipeline_schedules에서 확인할 수 있습니다(Developer 권한 필요). 결과는 #e2e-run-master Slack 채널에서 보고됩니다.

스테이징 테스트#

매일 밤 스케줄 파이프라인을 실행하여 스테이징을 테스트합니다. 이 파이프라인은 https://gitlab.com/gitlab-org/quality/staging/pipelines에서 확인할 수 있습니다(Developer 권한 필요). 결과는 #e2e-run-staging Slack 채널에서 보고됩니다.

머지 리퀘스트에서 코드 테스트#

엔드-투-엔드 테스트 파이프라인에서는 머지 리퀘스트 내 E2E 테스트 실행을 담당하는 파이프라인 설정을 설명합니다.

test-on-omnibus job 사용#

qa Stage의 e2e:test-on-omnibus-ee 수동 액션을 트리거하여 머지 리퀘스트에 대한 엔드-투-엔드 테스트를 실행할 수 있습니다(포크에서는 사용 불가).

이 작업은 머지 리퀘스트의 변경 사항으로 빌드된 커스텀 EE(Ultimate 라이선스 포함) Docker 이미지에 대해 엔드-투-엔드 테스트를 실행합니다.

엔드-투-엔드 테스트를 시작하는 수동 액션은 gitlab-org/omnibus-gitlab 머지 리퀘스트에서도 사용할 수 있습니다.

머지 결과 파이프라인 사용#

머지 결과 파이프라인에서는 소스 브랜치와 타깃 브랜치의 머지 결과가 포함된 새 ref에서 파이프라인이 실행됩니다.

머지 결과 파이프라인의 엔드-투-엔드 테스트는 머지 리퀘스트 소스 브랜치의 헤드 대신 새 ref를 사용합니다.

graph LR

A["x1y1z1 - master HEAD"] B["d1e1f1 - merged results (CI_COMMIT_SHA)"]

A --> B

B --> C["Merged results pipeline"] C --> D["E2E tests"]

커스텀 테스트 실행#

다운스트림 gitlab-qa-mirror 파이프라인에서 실행되는 기존 시나리오에는 많은 테스트가 포함되어 있지만, 기존 시나리오의 그룹과 다른 테스트 또는 테스트 그룹을 실행하고 싶을 때가 있습니다.

예를 들어, 불안정한 테스트를 격리 해제(dequarantine)할 때는 먼저 더 이상 불안정하지 않은지 확인하고 싶습니다. _ee:quarantine 수동 job을 실행하여 이를 확인할 수 있습니다. 수동 job의 이름(실행 아이콘이 아닌)을 선택하면 변수를 입력하라는 메시지가 표시됩니다. gitlab-qa와 함께 사용할 수 있는 변수뿐만 아니라 다음 변수도 사용할 수 있습니다:

변수	설명
QA_SCENARIO	실행할 시나리오 (기본값: Test::Instance::Image)
QA_TESTS	실행할 테스트 (기본값 없음, 즉 시나리오의 모든 테스트 실행). RSpec으로 테스트를 실행할 때와 동일하게 파일 경로 사용. 예: qa/specs/features/ee/browser_ui는 모든 EE UI 테스트 포함
QA_RSPEC_TAGS	추가할 RSpec 태그 (기본값: --tag quarantine)

현재 수동 job에서 커스텀 변수는 재시도 시 동일한 변수를 사용하지 않으므로, 동일한 테스트를 여러 번 실행하려면 각 custom-parallel job에 동일한 변수를 지정하세요(최대 10개의 사용 가능한 job 중 원하는 만큼).

선택적 테스트 실행#

머지 리퀘스트에서 실행되는 테스트 수를 제한하기 위해 실행할 테스트를 동적으로 선택합니다. 실행할 테스트를 결정하는 알고리즘은 변경된 파일과 머지 리퀘스트 라벨을 기반으로 합니다. 다음 기준에 따라 실행할 테스트가 결정됩니다:

qa 프레임워크 코드의 변경은 전체 테스트 스위트를 실행합니다.
qa 폴더의 특정 _spec.rb 파일 변경은 해당 테스트만 실행합니다. 이 경우 job을 병렬로 실행하는 데 knapsack이 사용되지 않습니다.

코드 경로 매핑 기반 선택적 테스트 실행#

coverband gem은 backend MR의 E2E 선택적 테스트 실행을 위해 비표준 방식으로 사용됩니다.
coverband는 COVERBAND_ENABLED 환경 변수가 설정된 경우에만 GitLab 애플리케이션에서 활성화됩니다. 이 변수는 master의 스케줄 e2e:test-on-gdk 파이프라인에서만 설정되며 MR 파이프라인에서는 설정되지 않습니다.
소스 코드 경로는 각 E2E 예제 시작 전과 각 E2E 예제 완료 후에 내부 API를 사용하여 매핑됩니다.
전체 통합 매핑은 GCS의 code-path-mappings 버킷에 업로드됩니다.
이 매핑은 backend MR에서 테스트를 선택하는 데 사용됩니다.

매핑 기반 선택적 테스트 실행은 현재 test-on-gdk 파이프라인에서 사용 중입니다. 자세한 내용은 에픽 47을 참고하세요.

선택적 테스트 실행 재정의#

선택적 테스트 실행을 재정의하고 전체 테스트 스위트를 트리거하려면 해당 머지 리퀘스트에 pipeline:run-all-e2e 라벨을 추가해야 합니다.

엔드-투-엔드 테스트 건너뛰기#

경우에 따라 엔드-투-엔드 테스트 스위트를 실행할 필요가 없을 수 있습니다.

예시는 다음과 같습니다:

"그냥 작동해야 하는 것들"
소규모 리팩토링
전체 스위트를 두 번 실행할 필요가 없는 리뷰 중 소규모 요청 변경

머지 리퀘스트에 pipeline:skip-e2e 라벨을 적용하여 엔드-투-엔드 테스트 실행을 건너뜁니다.

엔드-투-엔드 테스트를 건너뛰는 데는 위험이 따릅니다. 이 라벨을 적용할 때는 주의와 신중함을 발휘하세요. 엔드-투-엔드 테스트 스위트는 변경 사항이 기본 브랜치에 머지되기 전 마지막 방어선입니다. 이 테스트를 건너뛰면 코드베이스에 회귀를 도입할 위험이 증가합니다.

동적 병렬 job 스케일링#

일관된 파이프라인 실행 시간을 유지하기 위해, 각 E2E 테스트 스위트의 CI/CD job 수는 스위트의 총 테스트 실행 시간을 기반으로 동적으로 스케일링됩니다. generate_e2e_pipelines Rake 태스크는 다음을 수행하는 CI/CD YAML 파일을 생성합니다:

올바른 수의 병렬 job을 생성합니다.
실행될 테스트가 없는 경우 특정 job을 완전히 건너뜁니다.

이 기능은 선택적 테스트 실행과 연동하여 머지 리퀘스트 내의 특정 변경 사항에 따라 파이프라인 실행 시간과 비용을 최대한 최적화합니다.

설계 개요#

동적 job 스케일링은 Test Scenario 클래스에 의존합니다. 이 추상화는 다음을 캡슐화합니다:

특정 시나리오가 실행해야 하는 RSpec 태그.
시나리오를 특정 스펙 파일로 제한할 수 있는 선택적 스펙 파일 패턴.
특정 시나리오가 머지 리퀘스트 파이프라인에서 실행될 파이프라인 유형과 job을 정의하는 파이프라인 매핑.

PipelineCreator 클래스는 동적으로 조정된 병렬 job 수를 가진 파이프라인 YAML 파일을 생성합니다. 파이프라인 YAML 생성 전에 PipelineCreator는 정의된 모든 Test Scenario 클래스를 반복하고, 각 CI/CD job의 총 계산된 테스트 실행 시간을 포함하는 매핑을 생성합니다. 이 정보를 기반으로 올바르게 조정된 병렬 job 수를 가진 파이프라인 YAML 파일이 생성됩니다.

PipelineCreator는 추가적으로 선택적 테스트 실행의 입력을 받아 실행될 총 테스트 수를 더욱 줄입니다.

머지 리퀘스트 파이프라인에서 이 시나리오를 실행하고 병렬 job을 동적으로 스케일링하는 새 시나리오를 만드는 방법의 예시는 E2E 테스트 파이프라인에 새 job 추가를 참고하세요.

테스트 파이프라인 도구 및 구성#

테스트 병렬화#

CI 설정에서는 knapsack gem을 사용하여 테스트 병렬화를 지원합니다. Knapsack 보고서는 자동으로 생성되어 gitlab-qa-resources 프로젝트 내 knapsack-reports GCS 버킷에 저장됩니다. KnapsackReport 헬퍼가 보고서 생성 및 업로드 프로세스를 관리합니다.

테스트 메트릭#

테스트 상태 가시성을 향상시키기 위해, 커스텀 설정이 파이프라인의 테스트 실행 결과를 GCS 버킷으로 내보내며, 결과는 Snowflake 대시보드에서 시각화됩니다.

테스트 보고서#

Allure 보고서#

추가적인 테스트 결과 가시성을 위해, 파이프라인에서 실행되는 테스트는 Allure 테스트 보고서를 생성하고 호스팅합니다.

QA 프레임워크는 Allure RSpec gem을 사용하여 Allure 테스트 보고서의 소스 파일을 생성합니다. 파이프라인의 추가 job은 다음을 수행합니다:

모든 테스트 job에서 이 소스 파일을 가져옵니다.
AWS 그룹 프로젝트 eng-quality-ops-ci-cd-shared-infra의 S3 버킷 gitlab-qa-allure-report에 보고서를 생성하고 업로드합니다.

보고서 업로드를 위한 공통 CI 템플릿은 allure-report.yml에 저장되어 있습니다.

머지 리퀘스트#

이 테스트가 머지 리퀘스트 범위에서 실행될 때, Allure 보고서는 GCS 버킷에 업로드되고 해당 보고서에 연결하는 봇 댓글이 추가됩니다.

스케줄 파이프라인#

이 테스트의 스케줄 파이프라인에는 Report Stage 아래에 generate-allure-report job이 포함되어 있습니다. 또한 현재 테스트 보고서에 대한 링크를 출력합니다. 각 유형의 스케줄 파이프라인은 해당 Stage에 따라 최신 테스트 보고서에 대한 정적 링크를 생성합니다. 목록은 GitLab 핸드북에서 확인할 수 있습니다.

프로비저닝#

모든 컴포넌트의 프로비저닝은 engineering-productivity-infrastructure 프로젝트에서 수행됩니다.

CI에서 메트릭 내보내기#

메트릭 내보내기를 구성하려면 다음 환경 변수를 사용하세요:

변수	필수 여부	정보
QA_RUN_TYPE	false	e2e:test-on-omnibus-ee와 같은 테스트 실행의 임의 이름. 라이브 환경 테스트 실행의 경우 프로젝트 이름에서 자동으로 추론됩니다. 기본값 없음.
QA_EXPORT_TEST_METRICS	false	GCS로의 메트릭 내보내기를 활성화 또는 비활성화하는 플래그. 기본값은 false.

테스트를 어떻게 실행하나요?#

머지 리퀘스트에서 코드를 테스트하는 경우가 아니라면, 테스트를 실행하는 두 가지 주요 옵션이 있습니다. 라이브 GitLab 인스턴스 또는 사전 빌드된 Docker 이미지에 대해 기존 테스트를 실행하려면 GitLab QA orchestrator를 사용하세요. 또한 orchestrator를 사용하여 실행할 수 있는 테스트 시나리오 예시도 참고하세요.

반면, 로컬 개발 GitLab 환경에 대해 실행하려면 GitLab Development Kit(GDK)를 사용할 수 있습니다. QA README의 지침과 아래 섹션을 참고하세요.

특별 설정이 필요한 테스트 실행#

로컬 환경에서 특별한 설정이나 고려 사항이 필요한 테스트를 수행하는 방법을 알아보세요.

테스트를 어떻게 작성하나요?#

새 테스트를 작성하기 전에 GitLab QA 아키텍처를 검토하세요.

테스트 환경 오케스트레이션 시나리오와 인스턴스 레벨 시나리오를 어디에 배치할지 결정한 후, GitLab QA README, GitLab QA orchestrator README, 기존 인스턴스 레벨 시나리오를 살펴보세요.