개요#

이 페이지에서는 엔드 투 엔드 테스트 실패와 배포를 조사하고 여러 GitLab 환경의 문제를 해결하는 절차를 설명합니다. 실패를 처리하는 방법, 문제가 된 커밋을 식별하는 방법, 로깅 도구, 실패를 재현하는 방법을 다룹니다.

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

Staging-Canary#

Staging-Canary는 deployer 파이프라인이 트리거하는 차단성 smoke 테스트 측면에서 특수합니다. Staging-Canary는 Staging-Canary와 Staging 두 환경 모두에 대해 smoke 테스트를 실행합니다. 이 특수한 구성은 두 환경의 공유 컴포넌트와 비공유 컴포넌트 사이에 비호환이 생겼을 때 나타나는 이슈를 잡아내기 위한 것입니다.

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

#announcements Slack 채널에서 배포 실패를 확인할 때는 파이프라인으로 들어가 Downstream 결과를 살펴봐야 배포 실패가 Staging-Canary에서 발생했는지 Staging에서 발생했는지 파악할 수 있습니다.

더 자세한 컨텍스트와 다음 이미지의 비압축 버전은 공지 이슈에서 확인합니다.

이 다이어그램은 배포 후 마이그레이션의 차단 동작을 제거해 롤백 가용성을 높이는 작업의 일부로 갱신되었습니다.

Staging Ref#

Staging Ref는 최신 Staging Canary 코드를 프로덕션 반영 전에 테스트하는 데 쓰이는 샌드박스 환경입니다. 접근 권한이 넓은 공유 환경이므로 엔지니어가 자신의 코드를 테스트하는 과정에서 환경이 불안정해져 재구축이 필요할 수 있습니다.

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

Staging Ref 배포는 Staging Canary 배포와 병렬로 진행됩니다. 두 환경은 동일한 GitLab 버전을 사용합니다. Staging Canary에서는 발생하지 않는 실패가 Staging Ref 에서만 발생한다면 환경에 특유한 실패일 수 있습니다. E2E 테스트 실패를 조사하는 방법은 QA 파이프라인 디버깅 가이드를 참고합니다.

Preprod#

Preprod는 릴리스 후보를 검증하는 데 사용합니다. 매월 릴리스 날짜 전후와 그 며칠 전에는 릴리스를 지연시킬 수 있는 예기치 않은 파이프라인 실패가 없어야 합니다. 테스트나 테스트 환경의 문제를 미리 식별하고 해결할 수 있도록, 릴리스 후보 배포 전에 실행되는 예약 파이프라인이 있습니다. 이 예약 파이프라인의 실패는 릴리스에 영향을 줄 수 있으므로 Production 및 Staging 파이프라인과 동등한 우선순위로 다룹니다.

테스트 파이프라인은 설정 변경이 유효한지 확인하기 위해 Kubernetes 워크로드 설정 프로젝트에서도 트리거됩니다.

Nightly#

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

#quality Slack 채널에는 두 건의 알림이 전달됩니다.

1. 보안 릴리스가 시작되었다는 릴리스 팀의 공지.
2. 보안 릴리스가 게시되었다는 GitLab ChatOps의 알림.

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

보안 릴리스 이슈는 릴리스가 진행되기 전에 미리 생성되는 경우도 있습니다. 상태에 관해 궁금한 점이 있으면 Slack에서 @release-managers에게 문의할 수 있습니다.

master 파이프라인#

GitLab master에는 기본 브랜치를 대상으로 하는 예약 파이프라인에서 생성되는 QA 파이프라인이 두 개 있습니다.

• test-on-omnibus는 master에서 빌드된 omnibus Docker 이미지를 대상으로 엔드 투 엔드 테스트 full 스위트를 실행합니다.
• test-on-cng는 master에서 빌드된 클라우드 네이티브 GitLab 배포본을 대상으로 cng-instance job의 일부로 전체 엔드 투 엔드 테스트 스위트를 실행합니다.

test-on-omnibus의 job 이 GitLab Docker 이미지 문제로 실패했다면 Distribution 팀에 문의해 빌드의 알려진 문제인지 확인합니다.

master QA 파이프라인의 실패는 모두 Staging에 배포되므로, 파이프라인 초반에 실패를 잡으면 어떤 변경이 원인인지 찾아내고 더 빠르게 해결할 수 있습니다.

현재 환경 버전 확인#

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

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

/chatops gitlab run auto_deploy status

/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 이미지가 오래되어 특정 테스트가 실패한다고 의심된다면 다음 단계를 따릅니다.

1. 로컬에서 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 코드를 확인합니다.
2. 그다음 qa 디렉터리로 이동합니다(cd /home/qa/qa).
3. 마지막으로 cat으로 찾는 코드가 특정 파일에 있는지 확인합니다(예: cat page/project/issue/show.rb).

Note 다른 태그(예: nightly)에서 확인해야 한다면 위 1단계 스크립트 중 하나에서 태그를 변경합니다.

애플리케이션 코드 확인#

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 코드를 확인합니다.
2. 그다음 gitlab-rails 디렉터리로 이동합니다(cd /opt/gitlab/embedded/service/gitlab-rails/).
3. 마지막으로 cat으로 찾는 코드가 특정 파일에 있는지 확인합니다(예: cat public/assets/issues_analytics/components/issues_analytics-9c3887211ed5aa599c9eea63836486d04605f5dfdd76c49f9b05cc24b103f78a.vue).

Note 다른 태그(예: nightly)를 확인하려면 위 1단계 스크립트 중 하나에서 태그를 변경합니다.

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

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 입니다.
2. 해당 버전의 커밋 목록을 엽니다.
   • 버전 형식이 커밋 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 리포지터리에 해당 버전이 있는지 확인합니다.
3. 찾고 있던 머지 리퀘스트가 이 버전에 포함되어 있는지 확인합니다.
   • 머지 리퀘스트의 브랜치 이름을 기록합니다.
   • 2단계의 커밋을 브랜치 이름으로 검색합니다.
     • 커밋이 있으면 머지 리퀘스트가 이 버전에 포함된 것입니다. 예시를 참고합니다.
     • 결과가 없으면 머지 리퀘스트가 이 버전에 포함되지 않은 것입니다. 예시를 참고합니다.

테스트 실패 로그#

다음 항목이 조사에 도움이 됩니다.

Kibana 및 Sentry 로그#

E2E 테스트에서 요청이 실패해 서버에서 오류가 발생하면, job 로그에 해당 상관 ID가 포함된 Sentry 및 Kibana 로그 링크가 출력됩니다. 이 기능은 두 도구를 사용할 수 있는 환경에서 제공됩니다.

Kibana의 경우 링크가 두 개 제공됩니다. 하나는 Kibana Discover의 Rails 인덱스를 대상으로 하는 단일 검색으로 연결되고, 다른 하나는 여러 GitLab 컴포넌트의 검색 결과 패널을 담은 QA 상관 대시보드로 연결됩니다.

Kibana 상관 대시보드#

특정 상관 ID와 관련된 여러 GitLab 컴포넌트(예: Rails, Gitaly, Postgres 등)의 로그를 한곳에 모아 정리할 수 있도록 Kibana에 QA 상관 대시보드를 두고 있습니다.

• QA Correlation Dashboard - Staging
• QA Correlation Dashboard - Preprod
• QA Correlation Dashboard - Prod

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

이 대시보드는 Support 팀의 Correlation Dashboard와 유사하지만 Quality 팀의 필요에 맞게 조정할 수 있습니다.

테스트 실패 재현#

FIPS 모드로 실행 중인 GDK를 대상으로 테스트 실행#

FIPS와 관련된 이슈를 디버깅해야 한다면 GDK를 FIPS 모드로 사용할 수 있습니다.

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 환경을 대상으로 테스트 실행#

CustomersDot E2E 테스트를 staging 환경을 대상으로 로컬에서 실행하려면 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 문서와 특별한 설정이 필요한 테스트 실행 안내에서 확인할 수 있습니다.
• 테스트가 불안정한지 판단하려면 로그를 확인하거나 테스트를 몇 차례 실행합니다. 한 번이라도 통과하고 나머지는 실패한다면 불안정한 테스트입니다.

실패를 유발한 커밋 식별#

• 실패를 분류할 때 어떤 커밋이 실패를 유발했는지 찾아야 하는 경우가 많습니다. 최근 커밋 이력을 검토해 파악할 수 있는 경우도 있지만 그렇지 않은 경우도 있습니다. 실패가 유입된 지점을 빠르게 찾는 데는 Git bisect가 유용합니다.
• Git bisect 사용 시연은 교육 동영상에서 확인할 수 있습니다.

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

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

오케스트레이션 job에는 각각 다음 이름의 로그 파일이 아티팩트로 첨부됩니다.

• <container_name>-reconfigure-logs.txt - 컨테이너가 첫 시도에 정상적으로 실행된 경우
• <container_name>-retry-<retry_attempt>-reconfigure-logs.txt - 실패로 인해 GitLab 컨테이너 기동을 여러 번 시도한 경우

이 로그 파일에 오류가 있다면 gitlab-ctl reconfigure 명령과 관련된 문제입니다. #g_distribution 채널에서 distribution 팀에 문의합니다.

로컬에서 update-major 또는 update-minor 테스트 조사 및 자주 발생하는 실패#

update-major 또는 update-minor의 실패는 GitLab 업그레이드가 실패한다는 신호일 수 있습니다. 이러한 실패는 마이그레이션 이슈나 다른 변경으로 인해 발생할 수 있습니다. 고객이 업그레이드 중에 같은 문제를 겪지 않도록, 특히 릴리스 날짜가 가까운 시점에는 해당 오류를 우선순위로 조사합니다.

로컬에서 update-major 또는 update-minor 테스트 조사 및 자주 발생하는 실패 문서를 따릅니다.

테스트 라이선스#

E2E 테스트 파이프라인에서 사용하는 라이선스에 관한 자세한 내용은 테스트 라이선스 런북을 참고합니다.

교육 동영상#

• Quality Engineering: Failure Triage - Using Git bisect to identify commit that introduced a failure

추가 참조#

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