기능 플래그 E2E(end-to-end) 테스트#

스테이징·프로덕션 E2E 실행 워크플로#

예약 실행#

스테이징과 프로덕션 환경 모두에서 4시간마다 예약된 E2E 테스트를 실행합니다. 이 테스트는 최근 배포가 회귀를 유발하지 않았는지 확인하는 데 도움이 됩니다.

테스트 결과는 다음 Slack 채널에서 확인할 수 있습니다.

• #e2e-run-staging
• #e2e-run-production

머지 리퀘스트로 기능 플래그를 변경할 때의 E2E 흐름#

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

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

• cng-instance는 기능 플래그가 정의 파일의 기본값으로 설정됩니다.
• cng-instance-ff-inverse는 기능 플래그가 기본값의 반대로 설정됩니다.
• 오케스트레이션 테스트도 통과하는지 확인하려면 e2e:test-on-omnibus-ee job을 수동으로 트리거해야 합니다.

MR 이 승인되었으나 아직 머지되지 않은 경우#

• pipeline:tier-3 레이블이 자동으로 추가됩니다.
• E2E 테스트가 e2e:test-on-cng라는 다운스트림 파이프라인을 통해 실행됩니다.
• 이 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 이 끝날 때까지 기다립니다. 실행이 통과하면 배포가 안전하다는 뜻입니다. 실패하면 추가 롤아웃을 진행하기 전에 원인을 조사합니다.

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

기능 플래그 뒤에서 작업했으나 정의 파일은 변경하지 않았다면, 원래 변경 사항으로 초안 MR을 열고 정의 파일도 함께 수정해 cng-instance와 cng-instance-ff-inverse를 트리거하고 e2e:test-on-omnibus-ee도 수동으로 실행해, 원래 MR의 변경 사항이 E2E 테스트를 깨뜨리지 않는지 확인합니다.

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

ChatOps 명령으로 스테이징이나 프로덕션의 기능 플래그 값을 변경하면, 해당 E2E 실행 채널인 #e2e-run-staging 또는 #e2e-run-production으로 GitLab ChatOps 메시지가 전송됩니다.

파이프라인이 끝나면 결과를 담은 후속 메시지가 같은 Slack 채널로 전송됩니다. 파이프라인이 실패한 경우에는 아래 디버깅 안내 링크가 함께 포함됩니다.

메시지에 🚒 이모지가 붙어 있으면 파이프라인 트리아지 DRI가 이미 검토해 기능 플래그 변경과 무관한 알려진 실패로 판단했다는 뜻입니다. 💥 이모지가 붙어 있으면 기능 플래그 변경과 관련이 있을 수 있는 새로운 실패를 의미합니다.

기능 플래그 전환 파이프라인의 테스트 실패 디버깅#

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

알려진 실패 여부 판별#

1. 기능 플래그를 전환하기 전에 트리거된 이전 full run을 #e2e-run-staging 또는 #e2e-run-production Slack 채널에서 확인합니다. 같은 테스트가 같은 오류 메시지로 실패했다면 그 실패는 전환과 무관할 가능성이 높습니다.

2. 최근에 실패한 적은 없으나 테스트가 불안정한 경우에는 해당 테스트의 실패 이슈를 검색합니다.

   • Test Failure Issues 프로젝트의 이슈 목록에서 browser_ui/2_plan/issue/create_issue_spec.rb처럼 테스트 경로를 검색하고, 테스트 케이스 이슈 유형은 제외합니다.

   

   • 테스트 제목이 정확히 일치하는 이슈를 찾습니다. 같은 스펙 파일에 여러 테스트가 있을 수 있습니다.
   • 제목이 일치하는 이슈를 모두 열어, 실패한 기능 플래그 파이프라인과 같은 오류가 있는 이슈를 찾습니다.
   • 오류가 일치하는 실패 이슈가 있다면, Reports 섹션의 첫 실패가 기능 플래그 값이 변경되기 전에 생성된 파이프라인인지 확인합니다. 실패 이슈 자체가 기능 플래그 파이프라인에서 비롯된 것일 수 있기 때문입니다. 첫 실패가 변경 이전이라면 기능 플래그 전환이 원인이 아닐 가능성이 높습니다.

3. 실패한 job을 다시 실행합니다. 그래도 테스트가 실패하면 GDK 대상 E2E 테스트 실행으로 로컬에서 디버깅하거나 스테이징 대상 E2E 테스트 실행으로 스테이징에서 디버깅합니다.

GDK 대상 E2E 테스트 실행#

아직 준비하지 않았다면 GDK 설치 안내를 따라 로컬 GitLab 개발 환경을 구성합니다.

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 \ # Optional, to see the tests running
QA_LOG_LEVEL=DEBUG \ # Optional, to see more detailed logging
QA_GITLAB_URL="http://{GDK IP ADDRESS}:{GDK PORT}" \ # Needed if GDK url is not the default 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>

추가 링크#

• GDK 대상 E2E 테스트
• E2E 문제 해결
• 실행할 수 있는 E2E 테스트