피처 플래그로 테스트하기

특정 테스트를 실행할 때 피처 플래그를 활성화하려면 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가 지정되지 않은 경우, 또는 다른 scope가 지정되지 않은 경우 테스트는 canary, production, 및 pre-production에서만 건너뛰어집니다. 이는 관리자 액세스를 사용할 수 없기 때문입니다.

경고: 먼저 그룹, 프로젝트, 사용자를 위해 피처 플래그를 활성화하는 여러 방법을 시도하는 것이 좋습니다. 또는 기능 그룹을 참조하세요.

  • 전역 피처 플래그를 사용해야 하는 경우 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 = "기능 그룹"
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 호출 내에서 설정할 수 있습니다. 일관된 접근 방식을 위해:

  • 사용되는 것보다 활성화되지 않은 것을 확인합니다.
  • 변수명 뒤에 activated라는 단어를 추가합니다.
  • initialize 메소드 내에서 변수의 기본값을 설정합니다.

예를 들어: 

def initialize
  name_of_the_feature_flag_activated = false
  ...
end

정리

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

캐싱으로 인한 불안정성 관리

모든 응용 프로그램 설정 및 모든 피처 플래그가 GitLab 내에서 1분 동안 캐시됩니다. 테스트 중에는 모든 캐싱이 비활성화되지만 정적 환경에서는 예외입니다.

테스트가 피처 플래그를 변경하면, 활성 피처 플래그로만 표시되는 요소가 있는 경우에 불안정한 동작을 일으킬 수 있습니다. 이러한 동작을 우회하기 위해, 피처 플래그 뒤의 요소에 대한 대기를 추가하세요.

피처 플래그가 활성화된 시나리오 실행

기존 테스트를 편집하지 않고도 피처 플래그가 활성화된 전체 시나리오를 실행하는 것이 가능합니다.

자세한 내용은 QA README를 참조하세요.

피처 플래그가 활성화된 상태에서 엔드-투-엔드 테스트 통과 확인

Staging이나 GitLab.com에서 활성화되기 전에 피처 플래그가 활성화된 상태에서 엔드-투-엔드 테스트가 통과되어야 합니다. 업데이트가 필요한 테스트는 quad-planning의 일환으로 식별되어야 합니다. 관련 소프트웨어 엔지니어 테스트 담당자는 테스트를 업데이트하거나 다른 엔지니어에게 도움을 주는 것이 책임입니다. 그러나 변경 사항이 quad-planning을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 배포가 차단될 수 있습니다.

피처 플래그 정의가 변경될 때 자동 테스트 실행

엔드-투-엔드 테스트가 통과하는 것을 확인하는 두 가지 방법이 있습니다:

  • 만일 Merge Request이 피처 플래그 정의 파일을 추가하거나 편집하는 경우, 두 개의 e2e:package-and-test 작업 (ee:instance-parallel 및 ee:instance-parallel-ff-inverse)이 Merge Request 파이프라인에 자동으로 포함됩니다. 하나의 작업은 기본 피처 플래그 상태로 응용 프로그램을 실행하고 다른 하나는 그 반대 값을 설정합니다. 이러한 작업은 피처 플래그가 활성화되었을 때 또는 비활성화되었을 때 테스트 스위트를 실행하여 통과 여부를 확인합니다.
  • 경우에 따라, 엔드-투-엔드 테스트 작업이 자동으로 트리거되지 않았거나 기본 피처 플래그 값으로 테스트를 실행한 경우 (피처 플래그 값에 따라 엔드-투-엔드 테스트 실행), 피처 플래그를 활성화하는 드래프트 MR을 만들어 테스트가 피처 플래그가 활성화되었을 때 통과하는지 확인할 수 있습니다. 테스트가 통과하면 Merge Request을 닫을 수 있습니다. 테스트를 업데이트해야 하는 경우 관련 품질 부서의 안정적인 대응자 또는 귀하의 그룹에 안정적인 대응자가 없는 경우 다른 소프트웨어 엔지니어 테스트에게 연락하세요.

피처 플래그가 활성화된 상태에서 엔드-투-엔드 테스트 실패의 문제 해결

피처 플래그를 활성화하면 엔드-투-엔드 테스트 실패가 발생할 수 있습니다. 이 경우, 실패한 파이프라인의 아티팩트를 찾아 실패한 테스트의 스크린샷을 볼 수 있습니다. 그 후에 다음 중 하나를 수행할 수 있습니다:

기능 개발 중 테스트 실행

엔드-투-엔드 테스트가 피처 플래그를 활성화하면, Merge Request 파이프라인에서 e2e:package-and-test 작업을 실행하여 Merge Request에서 변경 사항을 테스트할 수 있습니다. 피처 플래그와 관련 변경 사항이 이미 Merge되어 있다면, 기본 브랜치에서 테스트를 통과하는지 확인할 수 있습니다. 엔드-투-엔드 테스트는 2시간마다 기본 브랜치에서 실행되고 결과는 Test Session Report, testcase-sessions 프로젝트에 게시됩니다. 만약 관련 테스트가 자체적으로 피처 플래그를 활성화하지 않는다면, 피처 플래그 정의 파일을 통해 기본적으로 플래그를 활성화하는 드래프트 Merge Request을 열어서 테스트를 업데이트해야 하는지 확인할 수 있습니다. 이렇게 하면 엔드-투-엔드 테스트 스위트를 자동으로 실행할 수 있습니다. 테스트가 통과하면 Merge Request을 닫을 수 있습니다. 테스트를 업데이트하는 데 도움이 필요한 경우, 관련 품질 부서의 안정적인 대응자 또는 귀하의 그룹에 안정적인 대응자가 없는 경우 다른 소프트웨어 엔지니어 테스트에게 연락하세요.