InfoGrab DocsInfoGrab Docs

E2E 테스트로 기능 플래그 테스트하기

요약

스테이징과 프로덕션 환경 모두에서 4시간마다 E2E 테스트를 스케줄에 따라 실행합니다. 다음 Slack 채널에서 테스트 결과를 모니터링할 수 있습니다: 머지 리퀘스트에서 기능 플래그 정의 파일이 추가되거나 변경된 경우, 다운스트림 E2E GDK job에서 2개의 파이프라인이 트리거됩니다:

Feature Flag E2E(end-to-end) 테스트#

스테이징 및 프로덕션에서의 E2E 실행 워크플로#

스케줄 실행#

스테이징과 프로덕션 환경 모두에서 4시간마다 E2E 테스트를 스케줄에 따라 실행합니다. 이 테스트는 최근 배포가 회귀(regression)를 도입하지 않았는지 확인하는 데 도움이 됩니다.

다음 Slack 채널에서 테스트 결과를 모니터링할 수 있습니다:

머지 리퀘스트로 기능 플래그 변경 시 E2E 플로우#

변경 내용에 기능 플래그 정의 파일이 포함된 경우#

머지 리퀘스트에서 기능 플래그 정의 파일이 추가되거나 변경된 경우, 다운스트림 E2E GDK job에서 2개의 파이프라인이 트리거됩니다:

  • gdk-instance는 기능 플래그 정의 파일의 기본값으로 기능 플래그가 설정됩니다.

  • gdk-instance-ff-inverse는 기능 플래그가 기본값의 반대로 설정됩니다.

  • e2e:test-on-omnibus-ee job은 오케스트레이션 테스트도 통과하는지 확인하기 위해 수동으로 트리거해야 합니다.

MR이 승인된 경우 (아직 머지되지 않은 상태)#

  • pipeline:tier-3 라벨이 자동으로 추가됩니다.

  • E2E 테스트는 e2e:test-on-cng와 e2e:test-on-gdk라는 이름의 다운스트림 파이프라인을 통해 실행됩니다.

  • 이러한 E2E job 중 하나라도 실패하면 파이프라인이 다음 단계로 진행되지 않도록 차단합니다. 테스트 결과는 E2E 봇이 머지 리퀘스트에 댓글로 게시하므로, 진행하기 전에 주의 깊게 검토하세요.

MR이 머지된 경우#

MR이 머지되고 커밋이 staging-canary, staging, production-canary, production 등의 환경에 자동 배포를 위해 선택된 후:

  • 기능 플래그 기본값이 MR에서 변경된 경우 #e2e-run-staging 또는 #e2e-run-production 채널에 ChatOps 메시지가 게시되지 않습니다. ChatOps 메시지는 /chatops 명령어를 사용하여 플래그를 토글할 때만 나타납니다.

  • #e2e-run-staging 및 #e2e-run-production 채널로 이동하여 다음 스케줄된 full run이 완료될 때까지 기다리세요. 실행이 통과되면 배포가 안전함을 확인하는 것입니다. 실패하는 경우 추가 롤아웃을 진행하기 전에 조사하세요.

[

](/19.1/development/testing_guide/end_to_end/img/successful-full-run_v18_0.png)

변경 내용에 기능 플래그 정의 파일이 포함되지 않은 경우#

기능 플래그 뒤에서 작업이 수행되었지만 정의 파일이 변경되지 않은 경우, 원본 변경 내용으로 드래프트 MR을 열고 정의 파일도 편집하여 gdk-instance와 gdk-instance-ff-inverse를 트리거하고, 원본 MR의 변경 내용이 E2E 테스트를 깨지 않는지 확인하기 위해 e2e:test-on-omnibus-ee도 수동으로 실행하세요.

스테이징 또는 프로덕션에서의 기능 플래그 값 변경#

스테이징 또는 프로덕션에서 ChatOps 명령어를 통해 기능 플래그 값이 변경되면, GitLab ChatOps 메시지가 Slack의 해당 E2E 실행 채널(#e2e-run-staging 또는 #e2e-run-production)로 전송됩니다.

[

](/19.1/development/testing_guide/end_to_end/img/gitlab-chatops-message_v18_0.png)

파이프라인이 완료되면, 결과가 담긴 후속 메시지가 동일한 Slack 채널로 전송됩니다. 파이프라인이 실패한 경우 아래 디버깅 지침에 대한 링크가 포함됩니다.

[

](/19.1/development/testing_guide/end_to_end/img/failed-pipeline-message_v18_0.png)

메시지에 🚒 이모지가 있는 경우, 파이프라인 트리아지 DRI가 이미 검토하여 기능 플래그 변경과 무관한 알려진 실패로 판단한 것입니다. 💥 이모지가 있는 경우, 기능 플래그 변경과 관련이 있을 수 있는 새로운 실패를 나타냅니다.

기능 플래그 토글 파이프라인에서의 테스트 실패 디버깅#

개별 테스트 오류를 보려면 Pipeline 링크를 클릭하여 실패한 job을 직접 확인하거나(ops.gitlab.net에 로그인되어 있어야 함), Allure Report를 클릭하여 실패한 테스트를 여세요. 그곳에서 스택 트레이스와 스크린샷을 포함한 사용 가능한 아티팩트를 확인할 수 있습니다.

실패가 알려진 문제인지 확인#

기능 플래그 토글 전에 트리거된 #e2e-run-staging 또는 #e2e-run-production Slack 채널의 이전 전체 실행 결과를 확인하세요. 동일한 테스트가 동일한 오류 메시지로 실패했다면, 해당 실패는 토글과 관련이 없을 가능성이 높습니다.

테스트가 최근에 실패한 적은 없지만 플레이키(flaky)한 경우, 테스트에 대한 실패 이슈를 검색하세요:

Test Failure Issues 프로젝트의 이슈 목록에서 테스트 경로(예: browser_ui/2_plan/issue/create_issue_spec.rb)를 검색하고 테스트 케이스 이슈 유형은 제외하세요.

[

](/19.1/development/testing_guide/end_to_end/img/failure-issue-search_v18_0.png)

  • 올바른 테스트 제목을 가진 이슈를 찾으세요. 동일한 스펙 파일에 여러 테스트가 있을 수 있습니다.

  • 제목과 일치하는 모든 이슈를 열고 실패한 기능 플래그 파이프라인의 오류와 동일한 오류가 있는 이슈를 찾으세요.

  • 일치하는 오류가 있는 실패 이슈가 있다면, Reports 섹션 아래의 첫 번째 실패가 기능 플래그 값이 변경되기 전에 생성된 파이프라인인지 확인하세요. 실패 이슈가 기능 플래그 파이프라인 자체에서 비롯된 것일 수 있기 때문입니다. 첫 번째 실패가 변경 이전이었다면, 기능 플래그 토글로 인한 것이 아닐 가능성이 높습니다.

실패한 job을 재실행하세요. 테스트가 여전히 실패하면, GDK 대상 E2E 테스트 실행 또는 스테이징 대상 E2E 테스트 실행을 통해 로컬에서 디버깅을 시도하세요.

GDK 대상 E2E 테스트 실행#

아직 완료하지 않은 경우, 로컬 GitLab 개발 환경으로 GDK 설치 지침을 따르세요.

GDK가 실행되면 필요에 따라 rails 콘솔에서 기능 플래그 값을 변경하세요.

기능 플래그를 활성화하려면:

bundle exec rails console
Feature.enable(:feature_flag_name)

기능 플래그를 비활성화하려면:

bundle exec rails console
Feature.disable(:feature_flag_name)

GDK URL을 방문하여 기능 플래그가 올바른 상태로 변경되었는지 확인하세요.

EE 테스트를 실행하려면 다음과 같이 라이선스를 설정해야 합니다:

export QA_EE_LICENSE=$(cat /path/to/gitlab_license)

gitlab/qa 디렉터리에서 실행하세요:

WEBDRIVER_HEADLESS=false \ # 선택 사항, 테스트 실행 화면을 보려면
QA_LOG_LEVEL=DEBUG \ # 선택 사항, 더 자세한 로그를 보려면
QA_GITLAB_URL="http://{GDK IP ADDRESS}:{GDK PORT}" \ # GDK URL이 기본값 http://localhost:3000이 아닌 경우 필요
bundle exec rspec qa/specs/features/<path/to/spec.rb>

스테이징 대상 E2E 테스트 실행#

캡차를 우회하려면 GITLAB_QA_USER_AGENT 환경 변수가 필요합니다. 값은 GSM에서 찾을 수 있습니다. 테스트에 관리자 액세스가 필요한 경우 GITLAB_ADMIN_USERNAME 및 GITLAB_ADMIN_PASSWORD도 필요할 수 있습니다.

gitlab/qa 디렉터리에서 실행하세요:

GITLAB_QA_USER_AGENT= \
GITLAB_USERNAME="gitlab-qa" \
GITLAB_PASSWORD= \
bundle exec bin/qa Test::Instance::All https://staging.gitlab.com -- qa/specs/features/<path/to/spec.rb>

추가 링크#

E2E 테스트로 기능 플래그 테스트하기

GitLab v19.1
원문 보기
요약

스테이징과 프로덕션 환경 모두에서 4시간마다 E2E 테스트를 스케줄에 따라 실행합니다. 다음 Slack 채널에서 테스트 결과를 모니터링할 수 있습니다: 머지 리퀘스트에서 기능 플래그 정의 파일이 추가되거나 변경된 경우, 다운스트림 E2E GDK job에서 2개의 파이프라인이 트리거됩니다:

Feature Flag E2E(end-to-end) 테스트#

스테이징 및 프로덕션에서의 E2E 실행 워크플로#

스케줄 실행#

스테이징과 프로덕션 환경 모두에서 4시간마다 E2E 테스트를 스케줄에 따라 실행합니다. 이 테스트는 최근 배포가 회귀(regression)를 도입하지 않았는지 확인하는 데 도움이 됩니다.

다음 Slack 채널에서 테스트 결과를 모니터링할 수 있습니다:

머지 리퀘스트로 기능 플래그 변경 시 E2E 플로우#

변경 내용에 기능 플래그 정의 파일이 포함된 경우#

머지 리퀘스트에서 기능 플래그 정의 파일이 추가되거나 변경된 경우, 다운스트림 E2E GDK job에서 2개의 파이프라인이 트리거됩니다:

  • gdk-instance는 기능 플래그 정의 파일의 기본값으로 기능 플래그가 설정됩니다.

  • gdk-instance-ff-inverse는 기능 플래그가 기본값의 반대로 설정됩니다.

  • e2e:test-on-omnibus-ee job은 오케스트레이션 테스트도 통과하는지 확인하기 위해 수동으로 트리거해야 합니다.

MR이 승인된 경우 (아직 머지되지 않은 상태)#

  • pipeline:tier-3 라벨이 자동으로 추가됩니다.

  • E2E 테스트는 e2e:test-on-cng와 e2e:test-on-gdk라는 이름의 다운스트림 파이프라인을 통해 실행됩니다.

  • 이러한 E2E job 중 하나라도 실패하면 파이프라인이 다음 단계로 진행되지 않도록 차단합니다. 테스트 결과는 E2E 봇이 머지 리퀘스트에 댓글로 게시하므로, 진행하기 전에 주의 깊게 검토하세요.

MR이 머지된 경우#

MR이 머지되고 커밋이 staging-canary, staging, production-canary, production 등의 환경에 자동 배포를 위해 선택된 후:

  • 기능 플래그 기본값이 MR에서 변경된 경우 #e2e-run-staging 또는 #e2e-run-production 채널에 ChatOps 메시지가 게시되지 않습니다. ChatOps 메시지는 /chatops 명령어를 사용하여 플래그를 토글할 때만 나타납니다.

  • #e2e-run-staging 및 #e2e-run-production 채널로 이동하여 다음 스케줄된 full run이 완료될 때까지 기다리세요. 실행이 통과되면 배포가 안전함을 확인하는 것입니다. 실패하는 경우 추가 롤아웃을 진행하기 전에 조사하세요.

[

](/19.1/development/testing_guide/end_to_end/img/successful-full-run_v18_0.png)

변경 내용에 기능 플래그 정의 파일이 포함되지 않은 경우#

기능 플래그 뒤에서 작업이 수행되었지만 정의 파일이 변경되지 않은 경우, 원본 변경 내용으로 드래프트 MR을 열고 정의 파일도 편집하여 gdk-instance와 gdk-instance-ff-inverse를 트리거하고, 원본 MR의 변경 내용이 E2E 테스트를 깨지 않는지 확인하기 위해 e2e:test-on-omnibus-ee도 수동으로 실행하세요.

스테이징 또는 프로덕션에서의 기능 플래그 값 변경#

스테이징 또는 프로덕션에서 ChatOps 명령어를 통해 기능 플래그 값이 변경되면, GitLab ChatOps 메시지가 Slack의 해당 E2E 실행 채널(#e2e-run-staging 또는 #e2e-run-production)로 전송됩니다.

[

](/19.1/development/testing_guide/end_to_end/img/gitlab-chatops-message_v18_0.png)

파이프라인이 완료되면, 결과가 담긴 후속 메시지가 동일한 Slack 채널로 전송됩니다. 파이프라인이 실패한 경우 아래 디버깅 지침에 대한 링크가 포함됩니다.

[

](/19.1/development/testing_guide/end_to_end/img/failed-pipeline-message_v18_0.png)

메시지에 🚒 이모지가 있는 경우, 파이프라인 트리아지 DRI가 이미 검토하여 기능 플래그 변경과 무관한 알려진 실패로 판단한 것입니다. 💥 이모지가 있는 경우, 기능 플래그 변경과 관련이 있을 수 있는 새로운 실패를 나타냅니다.

기능 플래그 토글 파이프라인에서의 테스트 실패 디버깅#

개별 테스트 오류를 보려면 Pipeline 링크를 클릭하여 실패한 job을 직접 확인하거나(ops.gitlab.net에 로그인되어 있어야 함), Allure Report를 클릭하여 실패한 테스트를 여세요. 그곳에서 스택 트레이스와 스크린샷을 포함한 사용 가능한 아티팩트를 확인할 수 있습니다.

실패가 알려진 문제인지 확인#

기능 플래그 토글 전에 트리거된 #e2e-run-staging 또는 #e2e-run-production Slack 채널의 이전 전체 실행 결과를 확인하세요. 동일한 테스트가 동일한 오류 메시지로 실패했다면, 해당 실패는 토글과 관련이 없을 가능성이 높습니다.

테스트가 최근에 실패한 적은 없지만 플레이키(flaky)한 경우, 테스트에 대한 실패 이슈를 검색하세요:

Test Failure Issues 프로젝트의 이슈 목록에서 테스트 경로(예: browser_ui/2_plan/issue/create_issue_spec.rb)를 검색하고 테스트 케이스 이슈 유형은 제외하세요.

[

](/19.1/development/testing_guide/end_to_end/img/failure-issue-search_v18_0.png)

  • 올바른 테스트 제목을 가진 이슈를 찾으세요. 동일한 스펙 파일에 여러 테스트가 있을 수 있습니다.

  • 제목과 일치하는 모든 이슈를 열고 실패한 기능 플래그 파이프라인의 오류와 동일한 오류가 있는 이슈를 찾으세요.

  • 일치하는 오류가 있는 실패 이슈가 있다면, Reports 섹션 아래의 첫 번째 실패가 기능 플래그 값이 변경되기 전에 생성된 파이프라인인지 확인하세요. 실패 이슈가 기능 플래그 파이프라인 자체에서 비롯된 것일 수 있기 때문입니다. 첫 번째 실패가 변경 이전이었다면, 기능 플래그 토글로 인한 것이 아닐 가능성이 높습니다.

실패한 job을 재실행하세요. 테스트가 여전히 실패하면, GDK 대상 E2E 테스트 실행 또는 스테이징 대상 E2E 테스트 실행을 통해 로컬에서 디버깅을 시도하세요.

GDK 대상 E2E 테스트 실행#

아직 완료하지 않은 경우, 로컬 GitLab 개발 환경으로 GDK 설치 지침을 따르세요.

GDK가 실행되면 필요에 따라 rails 콘솔에서 기능 플래그 값을 변경하세요.

기능 플래그를 활성화하려면:

bundle exec rails console
Feature.enable(:feature_flag_name)

기능 플래그를 비활성화하려면:

bundle exec rails console
Feature.disable(:feature_flag_name)

GDK URL을 방문하여 기능 플래그가 올바른 상태로 변경되었는지 확인하세요.

EE 테스트를 실행하려면 다음과 같이 라이선스를 설정해야 합니다:

export QA_EE_LICENSE=$(cat /path/to/gitlab_license)

gitlab/qa 디렉터리에서 실행하세요:

WEBDRIVER_HEADLESS=false \ # 선택 사항, 테스트 실행 화면을 보려면
QA_LOG_LEVEL=DEBUG \ # 선택 사항, 더 자세한 로그를 보려면
QA_GITLAB_URL="http://{GDK IP ADDRESS}:{GDK PORT}" \ # GDK URL이 기본값 http://localhost:3000이 아닌 경우 필요
bundle exec rspec qa/specs/features/<path/to/spec.rb>

스테이징 대상 E2E 테스트 실행#

캡차를 우회하려면 GITLAB_QA_USER_AGENT 환경 변수가 필요합니다. 값은 GSM에서 찾을 수 있습니다. 테스트에 관리자 액세스가 필요한 경우 GITLAB_ADMIN_USERNAME 및 GITLAB_ADMIN_PASSWORD도 필요할 수 있습니다.

gitlab/qa 디렉터리에서 실행하세요:

GITLAB_QA_USER_AGENT= \
GITLAB_USERNAME="gitlab-qa" \
GITLAB_PASSWORD= \
bundle exec bin/qa Test::Instance::All https://staging.gitlab.com -- qa/specs/features/<path/to/spec.rb>

추가 링크#