• feature_flag RSpec 태그
• 선택자 작업
  • 이전 예시
  • 이후 예시
• 리소스 클래스 작업
  • 정리
• 캐싱으로 인한 플래키니스 관리
• 기능 플래그가 활성화된 시나리오 실행
• 기능 플래그가 활성화된 상태에서 엔드 투 엔드 테스트가 통과하는지 확인
  • 기능 플래그 정의 변경 시 자동 테스트 실행
  • 기능 플래그 활성화 시 엔드 투 엔드 테스트 실패 해결
  • 기능 개발 중 테스트 실행

기능 플래그로 테스트하기

특정 테스트를 기능 플래그가 활성화된 상태로 실행하려면 QA::Runtime::Feature 클래스를 사용하여 기능 플래그를 활성화 및 비활성화할 수 있습니다 (API를 통해).

기능 플래그를 변경하려면 관리자 권한이 필요합니다. QA::Runtime::Feature 는 적절한 접근 토큰을 GITLAB_QA_ADMIN_ACCESS_TOKEN (권장)을 통해 제공하면 자동으로 관리자 권한으로 인증됩니다. 또는 GITLAB_ADMIN_USERNAME 과 GITLAB_ADMIN_PASSWORD를 제공할 수 있습니다.

feature_flag RSpec 태그

테스트가 적절한 환경에서 건너뛰어질 수 있도록 feature_flag 태그를 포함해야 합니다.

필수 메타데이터:

name

• 형식: feature_flag: { name: 'feature_flag_name' }
• 정보 제공 목적으로 사용됩니다. 어떤 기능 플래그가 테스트되고 있는지를 결정하기 위해 포함되어야 합니다.

선택적 메타데이터:

scope

• 형식: feature_flag: { name: 'feature_flag_name', scope: :project }
• scope가 :global로 설정되면, 테스트는 모든 라이브 .com 환경에서 건너뛰어집니다. 이는 기능 플래그 변경이 해당 환경의 다른 테스트나 사용자에게 영향을 미치는 문제를 피하기 위해서입니다.
• scope가 :project, :group 또는 :user와 같은 다른 값으로 설정되거나 scope가 지정되지 않은 경우, 테스트는 오직 캐너리, 프로덕션 및 사전 프로덕션 환경에서만 건너뛰어집니다. 이는 해당 곳에서 관리자 접근이 불가능하기 때문입니다.

경고: 먼저 그룹, 프로젝트, 사용자에 대해서만 기능 플래그를 활성화하거나 기능 그룹을 시도하는 것이 강력히 권장됩니다.

• 글로벌 기능 플래그를 사용해야 하는 경우, feature_flag 메타데이터에 scope: :global을 적용하는 것이 강력히 권장됩니다. 그러나 위험 수준을 결정하는 것은 SET의 재량에 맡깁니다.
  • 예를 들어, 전 세계 기능 플래그가 애플리케이션의 작은 영역에만 영향을 미치고 라이브 환경에서 중요한 문제를 점검하기 위해 필요한 경우입니다. 이러한 경우에는 테스트를 건너뛰는 것이 위험할 수 있습니다. 이러한 경우에는 scope를 메타데이터에서 제외하여 관리자 접근이 가능한 라이브 환경, 예를 들어 스테이징에서도 여전히 실행할 수 있도록 할 수 있습니다.

requires_admin에 대한 주의 사항: 이 태그는 기능 플래그 업데이트와 관련 없는 테스트 내에서 관리자 접근이 필요한 다른 작업이 있는 경우에도 여전히 적용해야 합니다 (API를 통해 사용자 생성 등).

아래 코드는 테스트에서 생성된 프로젝트에 대해 :feature_flag_name이라는 기능 플래그를 활성화합니다:

RSpec.describe "기능 플래그가 활성화된 상태로", feature_flag: {
  name: 'feature_flag_name',
  scope: :project
  } do

  let(:project) { Resource::Project.fabricate_via_api! }

  around do |example|
    Runtime::Feature.enable(:feature_flag_name, project: project)
    example.run
    Runtime::Feature.disable(:feature_flag_name, project: project)
  end

  it "기능 플래그 테스트" do
    # 기능 플래그가 활성화된 상태에서 테스트를 실행합니다.
    # 이것은 이 테스트에서 생성된 프로젝트에만 영향을 미칩니다.
  end
end

enable 및 disable 메서드는 먼저 플래그를 설정하고 그런 다음 API를 통해 업데이트된 값이 반환되는지 확인합니다.

유사하게 그룹, 사용자 또는 기능 그룹에 대해 기능을 활성화할 수 있습니다:

group = Resource::Group.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, group: group)

user = Resource::User.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, user: user)

feature_group = "a_feature_group"
Runtime::Feature.enable(:feature_flag_name, feature_group: feature_group)

scope가 제공되지 않으면 기능 플래그는 인스턴스 전체에 설정됩니다:

# 모든 사용자에게 영향을 미칠 것입니다!
Runtime::Feature.enable(:feature_flag_name)

선택자 작업

새로운 기능은 종종 vue 컴포넌트 또는 haml 파일을 새로운 것으로 교체합니다.

대부분의 경우, 새로운 파일 또는 컴포넌트는 기능 플래그가 활성화된 경우에만 접근할 수 있습니다.

이 접근 방식은 테스트가 기능 플래그가 활성화된 경우와 비활성화된 경우 모두 통과해야 할 때 문제가 됩니다.

두 시나리오 모두에서 테스트가 통과되도록 하려면:

1. 새 컴포넌트 또는 파일 내에 또 다른 선택자를 생성합니다.
2. 이전의 선택자와 동일한 이름을 부여합니다.

선택자는 페이지 객체의 특정 프론트엔드 파일에 연결되어 있으며, qa:selectors 테스트 내에서 가용성을 확인합니다. 언급된 선택자가 해당 프론트엔드 파일 내에 없으면 테스트가 실패합니다. 기능 플래그가 활성화되거나 비활성화될 때 선택자가 사용할 수 있도록 하려면, 새 선택자를 페이지 객체에 추가하고 기존 선택자는 그대로 두십시오. 그러면 테스트는 올바른 선택자를 사용하고 여전히 누락된 선택자를 감지합니다.

새로운 기능이 이미 선택자가 있는 기존 프론트엔드 파일을 변경하는 경우 동일한 이름의 새 선택자를 추가할 수 있습니다. 그러나 페이지에 표시되는 선택자는 하나만 존재합니다. 다음을 수행해야 합니다:

1. 기능 플래그로 다른 선택자를 비활성화합니다.
2. 기능 플래그가 제거될 때 기존 선택자를 프론트엔드 파일과 페이지 객체 파일에서 삭제하도록 프론트엔드 파일에 주석을 추가합니다.

이전 예시

# 이전 파일의 링크입니다
view 'app/views/devise/passwords/edit.html.haml' do
  # 새 선택자는 동일한 이름을 가져야 합니다
  element 'password-field'
  ...
end

이후 예시

view 'app/views/devise/passwords/edit.html.haml' do
  element 'password-field'
  ...
end

# 이제 선택자가 사용 가능한지 확인할 수 있습니다
view 'app/views/devise/passwords/new_edit_behind_ff.html.haml' do
  # 선택자는 동일한 이름입니다
  element 'password-field'
end

리소스 클래스 작업

리소스 클래스가 기능 플래그가 활성화된 경우 다르게 동작해야 하는 경우, 클래스 내에서 기능 플래그의 이름을 가진 변수를 전환하십시오. 이 변수와 조건은 모든 작업이 적절하게 처리되도록 합니다.

이 변수를 fabricate_via_api 호출 내에서 설정할 수 있습니다. 일관된 접근 방식을 위해:

• 비활성화된 것이 아닌 활성화된 체크를 사용합니다.
• 변수 이름 끝에 활성화된 단어를 추가합니다.
• initialize 메서드 내에서 변수의 기본값을 설정합니다.

예를 들어:

def initialize
  name_of_the_feature_flag_activated = false
  ...
end

정리

기능 플래그가 제거된 후 리소스 클래스를 정리하고 변수를 삭제하십시오. 모든 메서드는 이제 기본 상태의 조건 절차를 사용해야 합니다.

캐싱으로 인한 플래키니스 관리

모든 애플리케이션 설정 및 모든 기능 플래그는 GitLab 내에서 1분 동안 캐시됩니다.

테스트 중에는 모든 캐싱이 비활성화되며, 정적 환경에서만 활성화됩니다.

테스트가 기능 플래그를 변경하면, 활성화된 기능 플래그가 있는 경우에만 요소가 표시되므로, 불안정한 동작이 발생할 수 있습니다. 이러한 동작을 피하기 위해 기능 플래그 뒤에 있는 요소를 기다리도록 추가하십시오.

기능 플래그가 활성화된 시나리오 실행

기존 테스트를 수정하거나 새로운 테스트를 작성할 필요 없이 전체 시나리오를 기능 플래그가 활성화된 상태로 실행하는 것도 가능합니다.

자세한 내용은 QA README를 참조하십시오.

기능 플래그가 활성화된 상태에서 엔드 투 엔드 테스트가 통과하는지 확인

엔드 투 엔드 테스트는 Staging 또는 GitLab.com에서 기능 플래그가 활성화되기 전에 이를 통과해야 합니다. 업데이트가 필요한 테스트는 쿼드 계획의 일환으로 확인되어야 합니다. 관련 소프트웨어 엔지니어(테스트 분야) 담당자는 테스트를 업데이트하거나 다른 엔지니어가 이를 도울 수 있도록 책임집니다. 그러나 변경 사항이 쿼드 계획을 거치지 않으면 필요한 테스트 업데이트가 이루어지지 않을 수 있으며, 테스트 실패가 배포를 차단할 수 있습니다.

기능 플래그 정의 변경 시 자동 테스트 실행

엔드 투 엔드 테스트가 통과했는지 확인하는 방법은 두 가지가 있습니다:

• 병합 요청에서 기능 플래그 정의 파일을 추가하거나 수정하면, 두 개의 e2e:test-on-omnibus 작업(ee:instance-parallel 및 ee:instance-parallel-ff-inverse)이 자동으로 병합 요청 파이프라인에 포함됩니다. 하나의 작업은 기본 기능 플래그 상태로 애플리케이션을 실행하고 다른 하나는 이를 반대 값으로 설정합니다. 두 작업 모두 기능 플래그가 활성화되거나 비활성화된 상태에서 테스트가 통과하는지 확인하기 위해 동일한 테스트 모음을 실행합니다.

• 경우에 따라, 엔드 투 엔드 테스트 작업이 자동으로 트리거되지 않거나 기본 기능 플래그 값으로 테스트가 실행되었다면 (원하지 않을 수 있습니다), 기능 플래그를 활성화하는 Draft MR을 생성하여 모든 E2E 테스트가 기능 플래그가 활성화 및 비활성화된 상태에서 통과하는지 확인할 수 있습니다.

기능 플래그 활성화 시 엔드 투 엔드 테스트 실패 해결

기능 플래그를 활성화했을 때 E2E 테스트에 실패가 발생하면, 실패한 파이프라인에서 아티팩트를 찾아 실패한 테스트의 스크린샷을 확인할 수 있습니다. 이후에는 다음 중 하나를 수행할 수 있습니다:

• 업데이트가 필요한 테스트를 식별하고 테스트 업데이트를 담당하는 관련 소프트웨어 엔지니어와 연락하여 테스트를 업데이트하거나 다른 엔지니어를 지원할 수 있습니다. 그러나 변경 사항이 쿼드 계획을 통과하지 않고 필수 테스트 업데이트가 이루어지지 않으면, 테스트 실패로 인해 배포가 차단될 수 있습니다.

• 실패한 테스트를 로컬에서 실행하고 기능 플래그를 활성화합니다. 이 선택지는 상당한 설정이 필요하지만, 실패한 테스트를 실행하는 동안 브라우저에서 어떤 작업을 하고 있는지 확인할 수 있어 문제를 더 빠르게 디버깅하는 데 도움이 될 수 있습니다. 또한 E2E 테스트에 대한 문제 해결 가이드를 참조하여 일반적인 장애물에 대한 도움을 받을 수 있습니다.

기능 개발 중 테스트 실행

엔드 투 엔드 테스트에서 기능 플래그를 활성화하면, 병합 요청 파이프라인에서 e2e:test-on-omnibus 작업을 실행하여 병합 요청의 변경 사항을 테스트할 수 있습니다. 기능 플래그와 관련된 변경 사항이 이미 병합되었다면, 기본 브랜치에서 테스트가 통과하는지 확인할 수 있습니다. 엔드 투 엔드 테스트는 기본 브랜치에서 두 시간마다 실행되며, 결과는 테스트 세션 보고서에 게시되며, 이는 testcase-sessions 프로젝트에서 확인할 수 있습니다.

해당 테스트가 기능 플래그를 스스로 활성화하지 않는 경우, 기능 플래그 정의 파일을 통해 기본적으로 플래그를 활성화하는 드래프트 병합 요청을 열어야 테스트를 업데이트해야 할 필요가 있는지 확인할 수 있습니다. 그러면 기능 플래그 정의 변경 시 자동 테스트 실행이 자동으로 실행됩니다. 테스트가 통과하는 경우 병합 요청을 닫을 수 있습니다. 테스트 업데이트에 도움이 필요하면, 관련 품질 부서의 안정적인 동료에게 연락하거나 귀하의 그룹에 대한 안정적인 동료가 없을 경우 소프트웨어 엔지니어에게 문의하십시오.