InfoGrab DocsInfoGrab Docs

실패한 테스트 및 테스트 파이프라인 디버깅

요약

이 페이지에서는 엔드-투-엔드 테스트 실패, 배포, 다양한 GitLab 환경의 문제 해결을 위한 조사 단계를 설명합니다. Staging-Canary는 deployer 파이프라인에 의해 트리거되는 블로킹 smoke 테스트에 관해 고유한 환경입니다.

개요#

이 페이지에서는 엔드-투-엔드 테스트 실패, 배포, 다양한 GitLab 환경의 문제 해결을 위한 조사 단계를 설명합니다. 실패를 처리하는 방법, 문제가 된 커밋을 식별하는 방법, 로그 도구, 그리고 실패를 재현하는 방법에 대한 정보를 제공합니다.

특정 환경 조사 시 특별 고려사항#

Staging-Canary#

Staging-Canary는 deployer 파이프라인에 의해 트리거되는 블로킹 smoke 테스트에 관해 고유한 환경입니다. Staging-Canary는 Staging-Canary와 Staging 환경 모두에 대해 smoke 테스트를 실행합니다. 이 특별한 구성은 환경의 공유 컴포넌트와 비공유 컴포넌트 간에 비호환성이 발생할 때 생기는 문제를 포착하는 데 도움을 주기 위해 설계되었습니다.

예를 들어 Staging-Canary와 Staging은 동일한 데이터베이스(DB) 백엔드를 공유합니다. 배포 중 비공유 컴포넌트 중 하나에 대한 마이그레이션 또는 변경으로 인해 문제가 발생하면, 이 테스트를 함께 실행하면 해당 상황을 드러내는 데 도움이 됩니다. deployer 파이프라인이 이 테스트 실행을 트리거하면 #qa_staging Slack 채널에 순차적으로 보고되며, 서로 다른 실행으로 표시됩니다.

#announcements Slack 채널에서 배포 실패를 확인할 때는 파이프라인을 클릭하고 Downstream 결과를 살펴봐야 배포 실패가 Staging-Canary에서 발생했는지 아니면 Staging에서 발생했는지 알 수 있습니다.

자세한 컨텍스트 및 다음 이미지의 비압축 버전을 확인하려면 공지 이슈를 방문하세요:

[

](/19.1/development/testing_guide/end_to_end/img/deployment_pipeline_and_e2e_tests_v18_0.png)

다이어그램은 배포 후 마이그레이션의 블로킹 특성을 제거하여 롤백 가용성을 높이는 작업의 일환으로 업데이트되었습니다.

Staging Ref#

Staging Ref는 최신 Staging Canary 코드의 프로덕션 전 테스트를 위한 샌드박스 환경입니다. 광범위한 액세스 권한이 있는 공유 환경으로, 엔지니어들이 코드를 테스트하다 보면 환경이 불안정해지고 재구축이 필요할 수 있습니다.

전체 또는 smoke E2E 테스트 스위트는 staging-ref 프로젝트의 파이프라인 스케줄에서 필요에 따라 트리거할 수 있습니다.

Staging Ref 배포는 Staging Canary 배포와 병렬로 실행됩니다. 두 환경은 동일한 GitLab 버전을 공유하므로, Staging Ref에서는 실패하지만 Staging Canary에서는 실패하지 않는다면 해당 실패가 환경에 특정된 것일 수 있습니다. E2E 테스트 실패를 조사하는 방법에 대한 자세한 내용은 QA 파이프라인 디버깅 가이드를 참조하세요.

Preprod#

Preprod는 릴리즈 후보의 유효성 검사를 수행하는 데 사용됩니다. 매월 릴리즈 날짜 전후 며칠 동안은 릴리즈를 지연시킬 수 있는 파이프라인의 예기치 않은 실패가 없어야 합니다. 릴리즈 후보 배포 전에 파이프라인이 예약 실행되어 테스트 또는 테스트 환경의 문제를 미리 식별하고 해결할 기회를 제공합니다. 이 예약된 파이프라인은 릴리즈에 미치는 잠재적 영향으로 인해 Production 및 Staging 파이프라인과 동등한 우선순위를 부여해야 합니다.

구성 변경이 유효한지 확인하기 위해 Kubernetes Workload configuration project에서도 테스트 파이프라인이 트리거됩니다.

Nightly#

Omnibus nightly 빌드는 보안 릴리즈가 시작될 때 일시 중지되고 릴리즈가 완료되면 다시 활성화됩니다. 이로 인해 nightly 테스트가 오래된 패키지에 대해 실행되거나, 미러링이 중단된 경우 ce:sanity-version 및 ee:sanity-version job에서 실패할 수 있습니다.

#quality Slack 채널은 두 가지 알림을 받아야 합니다:

  • 보안 릴리즈 시작 시 릴리즈 팀으로부터의 공지.

  • 보안 릴리즈가 게시될 때 GitLab ChatOps로부터의 알림.

진행 중인 보안 릴리즈가 있는지 확인하는 다른 방법으로, #releases Slack 채널의 Next Security Release 북마크를 방문하거나 ~"upcoming security release" 라벨로 GitLab 프로젝트 이슈를 검색할 수 있습니다.

보안 릴리즈 이슈는 릴리즈가 진행되기 전에 생성될 수도 있음을 참고하세요. 상태에 대한 질문이 있으면 Slack에서 @release-managers에게 문의할 수도 있습니다.

master 파이프라인#

GitLab master에는 기본 브랜치에 대한 예약 파이프라인에서 생성되는 세 가지 QA 파이프라인이 있습니다:

  • test-on-omnibus는 master에서 빌드된 omnibus Docker 이미지에 대해 엔드-투-엔드 테스트의 full 스위트를 실행합니다.

  • test-on-gdk는 master에서 빌드된 Docker 이미지의 GDK 인스턴스에 대해 gdk-instance job의 일환으로 전체 엔드-투-엔드 테스트 스위트를 실행합니다.

test-on-omnibus의 job이 GitLab Docker 이미지 문제로 실패한 경우, 빌드의 알려진 문제인지 확인하기 위해 Distribution 팀에 문의하세요.

test-on-gdk job에서만 실패가 발생하는 경우, 원인이 수정되는 동안 해당 job이 새 파이프라인에 추가되지 않도록 중단할 수 있습니다. 자세한 내용은 런북을 참조하세요.

master QA 파이프라인의 모든 실패는 Staging에 배포되므로, 파이프라인의 앞 단계에서 실패를 포착하면 어떤 변경이 실패를 유발했는지 찾아내고 더 빠르게 해결할 수 있습니다.

현재 환경 버전 확인#

GitLab 환경에 배포된 버전, 리비전, 브랜치 및 패키지 확인#

GitLab.com, staging 및 canary 환경에 배포된 버전, 리비전, 브랜치 및 패키지를 확인하려면 #chat-ops-test Slack 채널에서 다음을 실행하세요:

/chatops gitlab run auto_deploy status

[

](/19.1/development/testing_guide/end_to_end/img/ChatopsAutoDeployStatus_v18_0.png)

/chatops 명령을 실행하려면 https://ops.gitlab.net/gitlab-com/chatops 프로젝트에 대한 액세스 권한이 필요합니다. #development Slack 채널에서 이 프로젝트에 추가해 달라고 요청하세요.

리비전 SHA를 사용하여 변경 사항이 환경에 배포되었는지 확인#

환경에 배포된 리비전 SHA가 있으면 특정 변경 사항이 해당 환경에 적용되었는지 확인할 수 있습니다. 예를 들어 환경에 배포된 리비전 SHA가 c46489109e4이고 restrict_by_ip_address_spec.rb의 변경 사항이 해당 환경에 적용되었는지 확인하려면 다음을 사용할 수 있습니다:

git show c46489109e4:qa/qa/specs/features/ee/browser_ui/1_manage/group/restrict_by_ip_address_spec.rb

GitLab 인스턴스에 배포된 리비전 SHA는 https://www.example.com/help 페이지로 이동하거나, https://www.example.com/api/v4/version API를 호출하거나, #chat-ops-test와 같은 Slack 채널에서 /chatops gitlab run auto_deploy status를 실행하여 확인할 수 있습니다.

ChatOps를 사용하여 커밋이 GitLab 환경에 배포되었는지 확인할 수도 있습니다. 예를 들어 커밋 ref가 347e530c5b3dec60c0ce2870bc79ca4c8273604d인 경우 #chat-ops-test와 같은 Slack 채널에서 다음 명령을 실행할 수 있습니다:

/chatops gitlab run auto_deploy status 347e530c5b3dec60c0ce2870bc79ca4c8273604d

nightly 이미지의 커밋 SHA 확인#

nightly 파이프라인의 커밋 SHA는 다음 방법으로 확인할 수 있습니다:

/help 페이지 방문 또는 /api/v4/version API 호출#

nightly Docker 이미지를 실행합니다:

docker run \
    --hostname localhost \
    --publish 443:443 --publish 80:80 --publish 22:22 \
gitlab/gitlab-ee:nightly

커밋 SHA는 로그인 후 http://localhost/help 페이지를 방문하거나 /api/v4/version API를 호출하여 확인할 수 있으며, revision 속성의 값으로 표시됩니다.

nightly 이미지를 생성한 파이프라인 검사#

nightly 이미지는 https://dev.gitlab.org/gitlab/omnibus-gitlab/pipeline_schedules의 예약 파이프라인에 의해 생성됩니다.

"Last pipeline" 칼럼의 CE nightly 또는 EE nightly의 파이프라인 번호를 클릭하면 마지막 파이프라인을 볼 수 있습니다.

파이프라인 뷰에서 GitLab_com:package 칼럼 아래의 job을 클릭하세요. GitLab 컴포넌트의 SHA가 로그 끝 부분에 나열됩니다. GitLab 커밋 SHA는 gitlab-rails의 값으로 표시됩니다.

Docker 이미지 확인#

테스트가 오래된 Docker 이미지로 인해 실패할 수 있습니다. 그런 경우인지 확인하려면 아래 지침에 따라 특정 병합된 코드가 Docker 이미지에서 사용 가능한지 확인하세요.

테스트 코드 확인 (QA 이미지)#

특정 테스트가 gitlab/gitlab-{ce|ee}-qa 이미지가 오래되어 실패한다고 의심되면 다음 단계를 따르세요:

  • 로컬에서 docker run -it --entrypoint /bin/sh gitlab/gitlab-ce-qa:latest를 실행하여 GitLab QA CE 코드를 확인하거나, docker run -it --entrypoint /bin/sh gitlab/gitlab-ee-qa:latest를 실행하여 GitLab QA EE 코드를 확인합니다.

  • 그런 다음 qa 디렉터리로 이동합니다 (cd /home/qa/qa).

  • 마지막으로 cat을 사용하여 특정 파일에서 찾고 있는 코드가 있는지 확인합니다 (예: cat page/project/issue/show.rb).

참고: 다른 태그(예: nightly)를 확인해야 하는 경우, 위의 1단계 스크립트 중 하나에서 태그를 변경하세요.

애플리케이션 코드 확인#

  • 로컬에서 docker run -it --entrypoint /bin/sh gitlab/gitlab-ce:latest를 실행하여 GitLab CE 코드를 확인하거나, docker run -it --entrypoint /bin/sh gitlab/gitlab-ee:latest를 실행하여 GitLab EE 코드를 확인합니다.

  • 그런 다음 gitlab-rails 디렉터리로 이동합니다 (cd /opt/gitlab/embedded/service/gitlab-rails/).

  • 마지막으로 cat을 사용하여 특정 파일에서 찾고 있는 코드가 있는지 없는지 확인합니다 (예: cat public/assets/issues_analytics/components/issues_analytics-9c3887211ed5aa599c9eea63836486d04605f5dfdd76c49f9b05cc24b103f78a.vue).

참고: 다른 태그(예: nightly)를 확인하려면 위의 1단계 스크립트 중 하나에서 태그를 변경하세요.

애플리케이션 버전에 특정 머지 리퀘스트가 포함되어 있는지 확인#

  • GitLab 애플리케이션이 실행 중인 버전을 찾습니다. 실패한 job 로그에서 docker pull dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee-qa를 검색하고 gitlab-ee-qa: 뒤에 지정된 버전을 사용하세요.

nightly의 경우 위 방법이 작동하지 않습니다. nightly의 커밋 버전을 찾는 두 가지 방법이 있습니다:

로컬에서 nightly 이미지를 실행하고 관리자로 로그인한 후 /help 페이지로 이동하거나 /api/v4/version API를 호출합니다.

  • 마지막 nightly를 빌드한 omnibus-GitLab 파이프라인에서 커밋을 검색합니다. nightly를 빌드하는 job은 Package-and-image Stage의 Docker-branch job에 bundle exec rake docker:push:nightly 명령이 있습니다. 최신 파이프라인을 찾으면 Gitlab_com:package Stage의 아무 job에서나 build-component_shas 아래의 gitlab-rails를 검색하세요. 예를 들어 이 Ubuntu-16.04-branch job에서 gitlab-rails의 커밋 SHA는 32e76bc4fb02a615c2bf5a00a8fceaee7812a6bd입니다.

  • 특정 버전의 커밋 목록을 엽니다:

버전 형식이 커밋 SHA처럼 보이는 경우 (예: gitlab-ee-qa:13.10-4b373026c98), https://gitlab.com/gitlab-org/gitlab/-/commits/<commit_SHA> 페이지로 이동하세요. 이 예시에서 커밋 SHA는 4b373026c98입니다.

버전 형식이 태그처럼 보이는 경우 (예: 13.10.0-rc20210223090520-ee), https://gitlab.com/gitlab-org/gitlab/-/commits/v<tag> 페이지로 이동하세요. 이 예시에서 태그는 13.10.0-rc20210223090520-ee입니다.

  • 위 페이지에서 404 오류가 반환되면 보안 릴리즈가 있는 경우 GitLab Security 리포지터리에 해당 버전이 존재하는지 확인하세요.

  • 검색하던 머지 리퀘스트(MR)가 이 버전에 포함되어 있는지 확인하세요.

MR의 브랜치 이름을 메모하세요.

  • 2단계의 커밋에서 브랜치 이름으로 검색합니다.

커밋이 발견되면 해당 MR이 이 버전에 포함되어 있습니다. 예시.

  • 결과가 없으면 해당 MR이 이 버전에 포함되어 있지 않습니다. 예시.

테스트 실패 로그#

다음은 조사에 도움이 될 수 있는 항목들입니다:

로그 또는 아티팩트 참고 사항
스택 트레이스 job 로그에 표시됨; 테스트 실패 조사의 시작점
스크린샷 및 HTML 캡처 job 실행 후 최대 1주일까지 job의 아티팩트에서 다운로드 가능
QA 로그 job의 아티팩트에 포함됨; 실패 전에 테스트가 수행한 단계를 파악하는 데 유용
시스템 로그 (GitLab-rails, Sidekiq 등) master 및 nightly와 같은 컨테이너화된 테스트 실행의 job 아티팩트에 포함됨. GitLab 애플리케이션 자체에서 발생하는 오류를 조사하는 데 유용합니다. master 및 nightly 실행에서 생성된 QA 실패 이슈의 설명에는 상관 ID가 포함된 테스트 실패와 관련된 시스템 로그 요약도 확인할 수 있습니다.
Sentry 로그 (Staging, Staging Ref, Preprod, Production) staging, preprod 또는 production 테스트가 서버 오류로 인해 실패하면 Sentry에 기록이 있어야 합니다. 예를 들어 is:unresolved user:"username:gitlab-qa" 쿼리로 gitlab-qa 사용자와 연결된 모든 미해결 staging 오류를 검색할 수 있습니다. 다만 일부 작업은 gitlab-qa 사용자와 연결되지 않아 전체 미해결 목록에서만 나타날 수 있습니다.
Kibana 로그 (Staging, Preprod, Production) Rails, Postgres, Sidekiq, Gitaly 로그를 포함한 다양한 시스템 로그가 라이브 환경에서 Kibana로 전송됩니다. 참고: Staging과 Preprod 로그는 동일한 URL을 사용하지만 검색 인덱스 패턴이 다릅니다. Staging 인덱스에는 gstg가 포함되고 Preprod에는 pre가 포함됩니다. 예를 들어 Staging Rails 인덱스 내에서 검색하려면 인덱스 패턴 드롭다운 값을 pubsub-rails-inf-gstg*로 변경해야 합니다. 자세한 내용은 Kibana 사용 페이지의 파라미터 섹션을 참조하세요.

Kibana 및 Sentry 로그#

E2E 테스트에서 요청이 실패하여 서버에서 오류가 발생하면, 해당 로그가 제공되는 환경에서는 job 로그에 Sentry 및 Kibana의 관련 상관 ID가 포함된 링크가 출력됩니다.

Kibana의 경우 두 개의 링크를 사용할 수 있습니다. 하나는 Kibana Discover의 Rails 인덱스에 대한 단일 검색으로 이동하고, 다른 하나는 여러 GitLab 컴포넌트의 검색 결과 패널이 포함된 QA 상관 대시보드로 이동합니다.

Kibana 상관 대시보드#

QA 상관 대시보드는 특정 상관 ID와 관련된 다양한 GitLab 컴포넌트(예: Rails, Gitaly, Postgres 등)의 로그를 한 곳에 정리하는 데 도움을 줍니다.

E2E 테스트 실패 로그에서 대시보드 링크가 자동으로 생성될 뿐만 아니라 이 대시보드에 직접 접속하여 수동으로 사용할 수도 있습니다. json.correlation_id 필터의 상관 ID를 원하는 ID로 교체하고 적절한 날짜 및 시간 범위를 설정하면 됩니다.

이는 지원 팀의 상관 대시보드와 유사하지만 Quality 팀의 필요에 맞게 커스터마이징할 수 있습니다.

테스트 실패 재현#

FIPS 모드에서 실행 중인 GDK에 대해 테스트 실행#

FIPS와 관련된 문제를 디버깅하려는 경우 FIPS 모드에서 GDK를 사용할 수 있습니다.

FIPS_MODE 변수를 사용하여 GDK를 재시작합니다:

FIPS_MODE=1 gdk restart

그런 다음 FIPS 변수를 설정하여 테스트를 실행할 수 있습니다:

FIPS=1 bundle exec bin/qa Test::Instance::All https://gdk.test:3000/ ./qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb

로컬 GDK에 대해 테스트 실행#

로컬 GitLab 인스턴스에서 테스트를 실행하거나 테스트 단계를 수동으로 수행하여 실패가 재현 가능한지 확인할 수 있습니다. 예시:

WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000 qa/specs/features/browser_ui/9_tenant_scale/project/create_project_spec.rb

오케스트레이션 테스트는 기본적으로 제외됩니다. 실행하려면 파일 이름 앞에 -- --tag orchestrated를 사용하세요. 예시:

WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000 -- --tag orchestrated qa/specs/features/browser_ui/9_tenant_scale/project/create_project_spec.rb

GitLab Docker 컨테이너에 대해 테스트 실행#

실패한 job에서 사용된 것과 동일한 Docker 이미지를 사용하여 로컬 컨테이너에서 GitLab을 실행할 수도 있습니다. 실패한 job의 로그에서 gitlab-ee 또는 gitlab-ce를 검색하고 해당 태그를 사용하여 로컬에서 컨테이너를 시작하세요.

이미지 태그를 확인했으면 로컬에서 GitLab 인스턴스를 시작하세요.

특별 고려사항

registry.gitlab.com에서 Docker 이미지를 가져오려면 컨테이너 레지스트리에 인증해야 합니다.

Nightly 이미지를 실행하려면 위의 Docker 명령 중 하나에서 registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<tag>를 gitlab/gitlab-ee:nightly 또는 gitlab/gitlab-ce:nightly로 변경하세요.

테스트 실행

이제 이 Docker 인스턴스에 대해 테스트를 실행할 수 있습니다. 예시:

WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/9_tenant_scale/project/create_project_spec.rb

CustomersDot staging 환경에 대해 테스트 실행#

staging 환경에서 로컬로 CustomersDot E2E 테스트를 실행하려면 CustomersDot 프로젝트를 클론하고 qa 디렉터리로 전환한 후 다음을 실행합니다:

STAGING=1 CP_ADMIN_TOKEN= GL_ADMIN_TOKEN= bundle exec rspec spec/ui/purchase/purchase_plan_spec.rb

참고 - 토큰 값은 GitLab-QA Vault에서 찾을 수 있습니다. 더 많은 옵션으로 로컬에서 테스트를 실행하는 방법에 대한 자세한 내용은 CustomersDot README 문서를 참조하세요.

로컬에서 테스트 실행 팁#

  • 환경 변수 QA_LOG_LEVEL=debug를 사용하여 페이지 작업 및 Git 명령을 포함한 추가 로그 출력을 활성화하세요.

  • 로컬에서 테스트를 실행하는 방법에 대한 추가 정보는 GitLab-qa 문서와 특별 설정이 필요한 테스트 실행 지침에서 찾을 수 있습니다.

  • 테스트가 플레이키(flaky)인지 확인하려면 로그를 확인하거나 테스트를 여러 번 실행하세요. 최소 한 번은 통과하지만 그렇지 않은 경우에 실패한다면 플레이키 테스트입니다.

실패를 도입한 커밋 식별#

  • 실패를 분류하는 동안 어떤 특정 커밋이 실패를 도입했는지 찾고 싶을 때가 있습니다. 최근 커밋 기록을 검토하여 식별할 수 있는 경우도 있지만, 그렇지 않은 경우도 있습니다. 실패가 도입된 위치를 빠르게 식별하는 데 Git bisect가 매우 유용할 수 있습니다.

  • Git bisect 사용에 관한 데모는 교육 동영상에서 확인할 수 있습니다.

오케스트레이션 테스트 실패 조사#

파이프라인 아티팩트에서 GitLab 컨테이너의 reconfigure 로그 확인#

각 오케스트레이션 job에는 다음과 같은 아티팩트로 첨부된 로그 파일이 있습니다:

  • 컨테이너가 첫 번째 시도에서 성공적으로 실행된 경우 <container_name>-reconfigure-logs.txt, 또는

  • 실패로 인해 GitLab 컨테이너를 여러 번 시작하려고 시도한 경우 <container_name>-retry-<retry_attempt>-reconfigure-logs.txt.

이 로그 파일에서 오류가 발견되면 gitlab-ctl reconfigure 명령과 관련된 문제일 수 있습니다. #g_distribution 채널의 distribution 팀에 문의하세요.

로컬에서 update-major 또는 update-minor 테스트 조사 및 일반적인 실패#

update-major 또는 update-minor에서의 실패는 GitLab 업그레이드가 실패했음을 나타낼 수 있습니다. 이러한 실패는 마이그레이션 문제나 기타 변경으로 인해 발생할 수 있습니다. 고객이 업그레이드 중에 이러한 문제를 겪지 않도록 특히 릴리즈 날짜 전후에는 우선적으로 오류를 조사하세요.

로컬에서 update-major 또는 update-minor 테스트 조사 및 일반적인 실패 문서를 따르세요.

테스트 라이선스#

E2E 테스트 파이프라인에서 사용하는 라이선스에 대한 자세한 내용은 테스트 라이선스 런북을 참조하세요.

교육 동영상#

추가 참조#

GitLab 엔드-투-엔드 테스트 문제 해결을 위한 일반 팁은 개발 문서에서 확인할 수 있습니다.

실패한 테스트 및 테스트 파이프라인 디버깅

GitLab v19.1
원문 보기
요약

이 페이지에서는 엔드-투-엔드 테스트 실패, 배포, 다양한 GitLab 환경의 문제 해결을 위한 조사 단계를 설명합니다. Staging-Canary는 deployer 파이프라인에 의해 트리거되는 블로킹 smoke 테스트에 관해 고유한 환경입니다.

개요#

이 페이지에서는 엔드-투-엔드 테스트 실패, 배포, 다양한 GitLab 환경의 문제 해결을 위한 조사 단계를 설명합니다. 실패를 처리하는 방법, 문제가 된 커밋을 식별하는 방법, 로그 도구, 그리고 실패를 재현하는 방법에 대한 정보를 제공합니다.

특정 환경 조사 시 특별 고려사항#

Staging-Canary#

Staging-Canary는 deployer 파이프라인에 의해 트리거되는 블로킹 smoke 테스트에 관해 고유한 환경입니다. Staging-Canary는 Staging-Canary와 Staging 환경 모두에 대해 smoke 테스트를 실행합니다. 이 특별한 구성은 환경의 공유 컴포넌트와 비공유 컴포넌트 간에 비호환성이 발생할 때 생기는 문제를 포착하는 데 도움을 주기 위해 설계되었습니다.

예를 들어 Staging-Canary와 Staging은 동일한 데이터베이스(DB) 백엔드를 공유합니다. 배포 중 비공유 컴포넌트 중 하나에 대한 마이그레이션 또는 변경으로 인해 문제가 발생하면, 이 테스트를 함께 실행하면 해당 상황을 드러내는 데 도움이 됩니다. deployer 파이프라인이 이 테스트 실행을 트리거하면 #qa_staging Slack 채널에 순차적으로 보고되며, 서로 다른 실행으로 표시됩니다.

#announcements Slack 채널에서 배포 실패를 확인할 때는 파이프라인을 클릭하고 Downstream 결과를 살펴봐야 배포 실패가 Staging-Canary에서 발생했는지 아니면 Staging에서 발생했는지 알 수 있습니다.

자세한 컨텍스트 및 다음 이미지의 비압축 버전을 확인하려면 공지 이슈를 방문하세요:

[

](/19.1/development/testing_guide/end_to_end/img/deployment_pipeline_and_e2e_tests_v18_0.png)

다이어그램은 배포 후 마이그레이션의 블로킹 특성을 제거하여 롤백 가용성을 높이는 작업의 일환으로 업데이트되었습니다.

Staging Ref#

Staging Ref는 최신 Staging Canary 코드의 프로덕션 전 테스트를 위한 샌드박스 환경입니다. 광범위한 액세스 권한이 있는 공유 환경으로, 엔지니어들이 코드를 테스트하다 보면 환경이 불안정해지고 재구축이 필요할 수 있습니다.

전체 또는 smoke E2E 테스트 스위트는 staging-ref 프로젝트의 파이프라인 스케줄에서 필요에 따라 트리거할 수 있습니다.

Staging Ref 배포는 Staging Canary 배포와 병렬로 실행됩니다. 두 환경은 동일한 GitLab 버전을 공유하므로, Staging Ref에서는 실패하지만 Staging Canary에서는 실패하지 않는다면 해당 실패가 환경에 특정된 것일 수 있습니다. E2E 테스트 실패를 조사하는 방법에 대한 자세한 내용은 QA 파이프라인 디버깅 가이드를 참조하세요.

Preprod#

Preprod는 릴리즈 후보의 유효성 검사를 수행하는 데 사용됩니다. 매월 릴리즈 날짜 전후 며칠 동안은 릴리즈를 지연시킬 수 있는 파이프라인의 예기치 않은 실패가 없어야 합니다. 릴리즈 후보 배포 전에 파이프라인이 예약 실행되어 테스트 또는 테스트 환경의 문제를 미리 식별하고 해결할 기회를 제공합니다. 이 예약된 파이프라인은 릴리즈에 미치는 잠재적 영향으로 인해 Production 및 Staging 파이프라인과 동등한 우선순위를 부여해야 합니다.

구성 변경이 유효한지 확인하기 위해 Kubernetes Workload configuration project에서도 테스트 파이프라인이 트리거됩니다.

Nightly#

Omnibus nightly 빌드는 보안 릴리즈가 시작될 때 일시 중지되고 릴리즈가 완료되면 다시 활성화됩니다. 이로 인해 nightly 테스트가 오래된 패키지에 대해 실행되거나, 미러링이 중단된 경우 ce:sanity-version 및 ee:sanity-version job에서 실패할 수 있습니다.

#quality Slack 채널은 두 가지 알림을 받아야 합니다:

  • 보안 릴리즈 시작 시 릴리즈 팀으로부터의 공지.

  • 보안 릴리즈가 게시될 때 GitLab ChatOps로부터의 알림.

진행 중인 보안 릴리즈가 있는지 확인하는 다른 방법으로, #releases Slack 채널의 Next Security Release 북마크를 방문하거나 ~"upcoming security release" 라벨로 GitLab 프로젝트 이슈를 검색할 수 있습니다.

보안 릴리즈 이슈는 릴리즈가 진행되기 전에 생성될 수도 있음을 참고하세요. 상태에 대한 질문이 있으면 Slack에서 @release-managers에게 문의할 수도 있습니다.

master 파이프라인#

GitLab master에는 기본 브랜치에 대한 예약 파이프라인에서 생성되는 세 가지 QA 파이프라인이 있습니다:

  • test-on-omnibus는 master에서 빌드된 omnibus Docker 이미지에 대해 엔드-투-엔드 테스트의 full 스위트를 실행합니다.

  • test-on-gdk는 master에서 빌드된 Docker 이미지의 GDK 인스턴스에 대해 gdk-instance job의 일환으로 전체 엔드-투-엔드 테스트 스위트를 실행합니다.

test-on-omnibus의 job이 GitLab Docker 이미지 문제로 실패한 경우, 빌드의 알려진 문제인지 확인하기 위해 Distribution 팀에 문의하세요.

test-on-gdk job에서만 실패가 발생하는 경우, 원인이 수정되는 동안 해당 job이 새 파이프라인에 추가되지 않도록 중단할 수 있습니다. 자세한 내용은 런북을 참조하세요.

master QA 파이프라인의 모든 실패는 Staging에 배포되므로, 파이프라인의 앞 단계에서 실패를 포착하면 어떤 변경이 실패를 유발했는지 찾아내고 더 빠르게 해결할 수 있습니다.

현재 환경 버전 확인#

GitLab 환경에 배포된 버전, 리비전, 브랜치 및 패키지 확인#

GitLab.com, staging 및 canary 환경에 배포된 버전, 리비전, 브랜치 및 패키지를 확인하려면 #chat-ops-test Slack 채널에서 다음을 실행하세요:

/chatops gitlab run auto_deploy status

[

](/19.1/development/testing_guide/end_to_end/img/ChatopsAutoDeployStatus_v18_0.png)

/chatops 명령을 실행하려면 https://ops.gitlab.net/gitlab-com/chatops 프로젝트에 대한 액세스 권한이 필요합니다. #development Slack 채널에서 이 프로젝트에 추가해 달라고 요청하세요.

리비전 SHA를 사용하여 변경 사항이 환경에 배포되었는지 확인#

환경에 배포된 리비전 SHA가 있으면 특정 변경 사항이 해당 환경에 적용되었는지 확인할 수 있습니다. 예를 들어 환경에 배포된 리비전 SHA가 c46489109e4이고 restrict_by_ip_address_spec.rb의 변경 사항이 해당 환경에 적용되었는지 확인하려면 다음을 사용할 수 있습니다:

git show c46489109e4:qa/qa/specs/features/ee/browser_ui/1_manage/group/restrict_by_ip_address_spec.rb

GitLab 인스턴스에 배포된 리비전 SHA는 https://www.example.com/help 페이지로 이동하거나, https://www.example.com/api/v4/version API를 호출하거나, #chat-ops-test와 같은 Slack 채널에서 /chatops gitlab run auto_deploy status를 실행하여 확인할 수 있습니다.

ChatOps를 사용하여 커밋이 GitLab 환경에 배포되었는지 확인할 수도 있습니다. 예를 들어 커밋 ref가 347e530c5b3dec60c0ce2870bc79ca4c8273604d인 경우 #chat-ops-test와 같은 Slack 채널에서 다음 명령을 실행할 수 있습니다:

/chatops gitlab run auto_deploy status 347e530c5b3dec60c0ce2870bc79ca4c8273604d

nightly 이미지의 커밋 SHA 확인#

nightly 파이프라인의 커밋 SHA는 다음 방법으로 확인할 수 있습니다:

/help 페이지 방문 또는 /api/v4/version API 호출#

nightly Docker 이미지를 실행합니다:

docker run \
    --hostname localhost \
    --publish 443:443 --publish 80:80 --publish 22:22 \
gitlab/gitlab-ee:nightly

커밋 SHA는 로그인 후 http://localhost/help 페이지를 방문하거나 /api/v4/version API를 호출하여 확인할 수 있으며, revision 속성의 값으로 표시됩니다.

nightly 이미지를 생성한 파이프라인 검사#

nightly 이미지는 https://dev.gitlab.org/gitlab/omnibus-gitlab/pipeline_schedules의 예약 파이프라인에 의해 생성됩니다.

"Last pipeline" 칼럼의 CE nightly 또는 EE nightly의 파이프라인 번호를 클릭하면 마지막 파이프라인을 볼 수 있습니다.

파이프라인 뷰에서 GitLab_com:package 칼럼 아래의 job을 클릭하세요. GitLab 컴포넌트의 SHA가 로그 끝 부분에 나열됩니다. GitLab 커밋 SHA는 gitlab-rails의 값으로 표시됩니다.

Docker 이미지 확인#

테스트가 오래된 Docker 이미지로 인해 실패할 수 있습니다. 그런 경우인지 확인하려면 아래 지침에 따라 특정 병합된 코드가 Docker 이미지에서 사용 가능한지 확인하세요.

테스트 코드 확인 (QA 이미지)#

특정 테스트가 gitlab/gitlab-{ce|ee}-qa 이미지가 오래되어 실패한다고 의심되면 다음 단계를 따르세요:

  • 로컬에서 docker run -it --entrypoint /bin/sh gitlab/gitlab-ce-qa:latest를 실행하여 GitLab QA CE 코드를 확인하거나, docker run -it --entrypoint /bin/sh gitlab/gitlab-ee-qa:latest를 실행하여 GitLab QA EE 코드를 확인합니다.

  • 그런 다음 qa 디렉터리로 이동합니다 (cd /home/qa/qa).

  • 마지막으로 cat을 사용하여 특정 파일에서 찾고 있는 코드가 있는지 확인합니다 (예: cat page/project/issue/show.rb).

참고: 다른 태그(예: nightly)를 확인해야 하는 경우, 위의 1단계 스크립트 중 하나에서 태그를 변경하세요.

애플리케이션 코드 확인#

  • 로컬에서 docker run -it --entrypoint /bin/sh gitlab/gitlab-ce:latest를 실행하여 GitLab CE 코드를 확인하거나, docker run -it --entrypoint /bin/sh gitlab/gitlab-ee:latest를 실행하여 GitLab EE 코드를 확인합니다.

  • 그런 다음 gitlab-rails 디렉터리로 이동합니다 (cd /opt/gitlab/embedded/service/gitlab-rails/).

  • 마지막으로 cat을 사용하여 특정 파일에서 찾고 있는 코드가 있는지 없는지 확인합니다 (예: cat public/assets/issues_analytics/components/issues_analytics-9c3887211ed5aa599c9eea63836486d04605f5dfdd76c49f9b05cc24b103f78a.vue).

참고: 다른 태그(예: nightly)를 확인하려면 위의 1단계 스크립트 중 하나에서 태그를 변경하세요.

애플리케이션 버전에 특정 머지 리퀘스트가 포함되어 있는지 확인#

  • GitLab 애플리케이션이 실행 중인 버전을 찾습니다. 실패한 job 로그에서 docker pull dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee-qa를 검색하고 gitlab-ee-qa: 뒤에 지정된 버전을 사용하세요.

nightly의 경우 위 방법이 작동하지 않습니다. nightly의 커밋 버전을 찾는 두 가지 방법이 있습니다:

로컬에서 nightly 이미지를 실행하고 관리자로 로그인한 후 /help 페이지로 이동하거나 /api/v4/version API를 호출합니다.

  • 마지막 nightly를 빌드한 omnibus-GitLab 파이프라인에서 커밋을 검색합니다. nightly를 빌드하는 job은 Package-and-image Stage의 Docker-branch job에 bundle exec rake docker:push:nightly 명령이 있습니다. 최신 파이프라인을 찾으면 Gitlab_com:package Stage의 아무 job에서나 build-component_shas 아래의 gitlab-rails를 검색하세요. 예를 들어 이 Ubuntu-16.04-branch job에서 gitlab-rails의 커밋 SHA는 32e76bc4fb02a615c2bf5a00a8fceaee7812a6bd입니다.

  • 특정 버전의 커밋 목록을 엽니다:

버전 형식이 커밋 SHA처럼 보이는 경우 (예: gitlab-ee-qa:13.10-4b373026c98), https://gitlab.com/gitlab-org/gitlab/-/commits/<commit_SHA> 페이지로 이동하세요. 이 예시에서 커밋 SHA는 4b373026c98입니다.

버전 형식이 태그처럼 보이는 경우 (예: 13.10.0-rc20210223090520-ee), https://gitlab.com/gitlab-org/gitlab/-/commits/v<tag> 페이지로 이동하세요. 이 예시에서 태그는 13.10.0-rc20210223090520-ee입니다.

  • 위 페이지에서 404 오류가 반환되면 보안 릴리즈가 있는 경우 GitLab Security 리포지터리에 해당 버전이 존재하는지 확인하세요.

  • 검색하던 머지 리퀘스트(MR)가 이 버전에 포함되어 있는지 확인하세요.

MR의 브랜치 이름을 메모하세요.

  • 2단계의 커밋에서 브랜치 이름으로 검색합니다.

커밋이 발견되면 해당 MR이 이 버전에 포함되어 있습니다. 예시.

  • 결과가 없으면 해당 MR이 이 버전에 포함되어 있지 않습니다. 예시.

테스트 실패 로그#

다음은 조사에 도움이 될 수 있는 항목들입니다:

로그 또는 아티팩트 참고 사항
스택 트레이스 job 로그에 표시됨; 테스트 실패 조사의 시작점
스크린샷 및 HTML 캡처 job 실행 후 최대 1주일까지 job의 아티팩트에서 다운로드 가능
QA 로그 job의 아티팩트에 포함됨; 실패 전에 테스트가 수행한 단계를 파악하는 데 유용
시스템 로그 (GitLab-rails, Sidekiq 등) master 및 nightly와 같은 컨테이너화된 테스트 실행의 job 아티팩트에 포함됨. GitLab 애플리케이션 자체에서 발생하는 오류를 조사하는 데 유용합니다. master 및 nightly 실행에서 생성된 QA 실패 이슈의 설명에는 상관 ID가 포함된 테스트 실패와 관련된 시스템 로그 요약도 확인할 수 있습니다.
Sentry 로그 (Staging, Staging Ref, Preprod, Production) staging, preprod 또는 production 테스트가 서버 오류로 인해 실패하면 Sentry에 기록이 있어야 합니다. 예를 들어 is:unresolved user:"username:gitlab-qa" 쿼리로 gitlab-qa 사용자와 연결된 모든 미해결 staging 오류를 검색할 수 있습니다. 다만 일부 작업은 gitlab-qa 사용자와 연결되지 않아 전체 미해결 목록에서만 나타날 수 있습니다.
Kibana 로그 (Staging, Preprod, Production) Rails, Postgres, Sidekiq, Gitaly 로그를 포함한 다양한 시스템 로그가 라이브 환경에서 Kibana로 전송됩니다. 참고: Staging과 Preprod 로그는 동일한 URL을 사용하지만 검색 인덱스 패턴이 다릅니다. Staging 인덱스에는 gstg가 포함되고 Preprod에는 pre가 포함됩니다. 예를 들어 Staging Rails 인덱스 내에서 검색하려면 인덱스 패턴 드롭다운 값을 pubsub-rails-inf-gstg*로 변경해야 합니다. 자세한 내용은 Kibana 사용 페이지의 파라미터 섹션을 참조하세요.

Kibana 및 Sentry 로그#

E2E 테스트에서 요청이 실패하여 서버에서 오류가 발생하면, 해당 로그가 제공되는 환경에서는 job 로그에 Sentry 및 Kibana의 관련 상관 ID가 포함된 링크가 출력됩니다.

Kibana의 경우 두 개의 링크를 사용할 수 있습니다. 하나는 Kibana Discover의 Rails 인덱스에 대한 단일 검색으로 이동하고, 다른 하나는 여러 GitLab 컴포넌트의 검색 결과 패널이 포함된 QA 상관 대시보드로 이동합니다.

Kibana 상관 대시보드#

QA 상관 대시보드는 특정 상관 ID와 관련된 다양한 GitLab 컴포넌트(예: Rails, Gitaly, Postgres 등)의 로그를 한 곳에 정리하는 데 도움을 줍니다.

E2E 테스트 실패 로그에서 대시보드 링크가 자동으로 생성될 뿐만 아니라 이 대시보드에 직접 접속하여 수동으로 사용할 수도 있습니다. json.correlation_id 필터의 상관 ID를 원하는 ID로 교체하고 적절한 날짜 및 시간 범위를 설정하면 됩니다.

이는 지원 팀의 상관 대시보드와 유사하지만 Quality 팀의 필요에 맞게 커스터마이징할 수 있습니다.

테스트 실패 재현#

FIPS 모드에서 실행 중인 GDK에 대해 테스트 실행#

FIPS와 관련된 문제를 디버깅하려는 경우 FIPS 모드에서 GDK를 사용할 수 있습니다.

FIPS_MODE 변수를 사용하여 GDK를 재시작합니다:

FIPS_MODE=1 gdk restart

그런 다음 FIPS 변수를 설정하여 테스트를 실행할 수 있습니다:

FIPS=1 bundle exec bin/qa Test::Instance::All https://gdk.test:3000/ ./qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb

로컬 GDK에 대해 테스트 실행#

로컬 GitLab 인스턴스에서 테스트를 실행하거나 테스트 단계를 수동으로 수행하여 실패가 재현 가능한지 확인할 수 있습니다. 예시:

WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000 qa/specs/features/browser_ui/9_tenant_scale/project/create_project_spec.rb

오케스트레이션 테스트는 기본적으로 제외됩니다. 실행하려면 파일 이름 앞에 -- --tag orchestrated를 사용하세요. 예시:

WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000 -- --tag orchestrated qa/specs/features/browser_ui/9_tenant_scale/project/create_project_spec.rb

GitLab Docker 컨테이너에 대해 테스트 실행#

실패한 job에서 사용된 것과 동일한 Docker 이미지를 사용하여 로컬 컨테이너에서 GitLab을 실행할 수도 있습니다. 실패한 job의 로그에서 gitlab-ee 또는 gitlab-ce를 검색하고 해당 태그를 사용하여 로컬에서 컨테이너를 시작하세요.

이미지 태그를 확인했으면 로컬에서 GitLab 인스턴스를 시작하세요.

특별 고려사항

registry.gitlab.com에서 Docker 이미지를 가져오려면 컨테이너 레지스트리에 인증해야 합니다.

Nightly 이미지를 실행하려면 위의 Docker 명령 중 하나에서 registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<tag>를 gitlab/gitlab-ee:nightly 또는 gitlab/gitlab-ce:nightly로 변경하세요.

테스트 실행

이제 이 Docker 인스턴스에 대해 테스트를 실행할 수 있습니다. 예시:

WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/9_tenant_scale/project/create_project_spec.rb

CustomersDot staging 환경에 대해 테스트 실행#

staging 환경에서 로컬로 CustomersDot E2E 테스트를 실행하려면 CustomersDot 프로젝트를 클론하고 qa 디렉터리로 전환한 후 다음을 실행합니다:

STAGING=1 CP_ADMIN_TOKEN= GL_ADMIN_TOKEN= bundle exec rspec spec/ui/purchase/purchase_plan_spec.rb

참고 - 토큰 값은 GitLab-QA Vault에서 찾을 수 있습니다. 더 많은 옵션으로 로컬에서 테스트를 실행하는 방법에 대한 자세한 내용은 CustomersDot README 문서를 참조하세요.

로컬에서 테스트 실행 팁#

  • 환경 변수 QA_LOG_LEVEL=debug를 사용하여 페이지 작업 및 Git 명령을 포함한 추가 로그 출력을 활성화하세요.

  • 로컬에서 테스트를 실행하는 방법에 대한 추가 정보는 GitLab-qa 문서와 특별 설정이 필요한 테스트 실행 지침에서 찾을 수 있습니다.

  • 테스트가 플레이키(flaky)인지 확인하려면 로그를 확인하거나 테스트를 여러 번 실행하세요. 최소 한 번은 통과하지만 그렇지 않은 경우에 실패한다면 플레이키 테스트입니다.

실패를 도입한 커밋 식별#

  • 실패를 분류하는 동안 어떤 특정 커밋이 실패를 도입했는지 찾고 싶을 때가 있습니다. 최근 커밋 기록을 검토하여 식별할 수 있는 경우도 있지만, 그렇지 않은 경우도 있습니다. 실패가 도입된 위치를 빠르게 식별하는 데 Git bisect가 매우 유용할 수 있습니다.

  • Git bisect 사용에 관한 데모는 교육 동영상에서 확인할 수 있습니다.

오케스트레이션 테스트 실패 조사#

파이프라인 아티팩트에서 GitLab 컨테이너의 reconfigure 로그 확인#

각 오케스트레이션 job에는 다음과 같은 아티팩트로 첨부된 로그 파일이 있습니다:

  • 컨테이너가 첫 번째 시도에서 성공적으로 실행된 경우 <container_name>-reconfigure-logs.txt, 또는

  • 실패로 인해 GitLab 컨테이너를 여러 번 시작하려고 시도한 경우 <container_name>-retry-<retry_attempt>-reconfigure-logs.txt.

이 로그 파일에서 오류가 발견되면 gitlab-ctl reconfigure 명령과 관련된 문제일 수 있습니다. #g_distribution 채널의 distribution 팀에 문의하세요.

로컬에서 update-major 또는 update-minor 테스트 조사 및 일반적인 실패#

update-major 또는 update-minor에서의 실패는 GitLab 업그레이드가 실패했음을 나타낼 수 있습니다. 이러한 실패는 마이그레이션 문제나 기타 변경으로 인해 발생할 수 있습니다. 고객이 업그레이드 중에 이러한 문제를 겪지 않도록 특히 릴리즈 날짜 전후에는 우선적으로 오류를 조사하세요.

로컬에서 update-major 또는 update-minor 테스트 조사 및 일반적인 실패 문서를 따르세요.

테스트 라이선스#

E2E 테스트 파이프라인에서 사용하는 라이선스에 대한 자세한 내용은 테스트 라이선스 런북을 참조하세요.

교육 동영상#

추가 참조#

GitLab 엔드-투-엔드 테스트 문제 해결을 위한 일반 팁은 개발 문서에서 확인할 수 있습니다.