GitLab의 기능 플래그

note
이 문서에서는 GitLab 제품의 개발 및 운영에 기여하는 방법을 설명합니다.
자신의 애플리케이션에서 기능을 표시하고 숨기기 위해 기능 플래그를 사용하려면,
이 기능 플래그 정보를 대신 확인하세요.
caution
모든 새로 도입된 기능 플래그는 기본적으로 비활성화되어야 합니다.
caution
모든 새로 도입된 기능 플래그는 행위자와 함께 사용해야 합니다.

설계 문서:

이 문서는 기능 플래그의 내부 사용 개선 일환으로 지속적인 작업의 주제입니다. 제안 사항은 새로운 문제로 제기하고 에픽에 첨부하세요.

기능 플래그 생애 주기 개요를 확인하거나, 기능 플래그를 사용해야 하는지를 결정하는 데 도움이 필요하다면, 기능 플래그 생애 주기 핸드북 페이지를 참조하세요.

기능 플래그를 사용하는 시기

핸드북의 “기능 플래그 사용 시기” 섹션으로 이동했습니다.

장기 설정에 기능 플래그를 사용하지 마십시오

기능 플래그는 짧은 생애를 가지고 있습니다.
사용자/그룹/프로젝트별로 긴 시간 동안 어떤 것을 활성화하기 위해 기능 플래그를 추가하려는 경우,
Cascading Settings 또는 Application Settings를 도입하는 것을 고려하세요.
설정은 고객이 GitLab.com 또는 자체 관리에서 자신의 기능을 활성화하거나 비활성화할 수 있는 방법을 제공합니다.
반면, 사용자는 GitLab.com에서 기능 플래그를 활성화하거나 비활성화할 수 있는 방법이 없으며,
자체 관리된 관리자만 기능 플래그를 변경할 수 있습니다.
또한 기능 플래그는 GitLab Dedicated에서는 지원되지 않습니다,
그래서 설정을 대체하는 용도로 사용해서는 안 됩니다.

GitLab 개발에서의 기능 플래그

기능 플래그를 활용해야 할지 결정할 때 고려해야 할 사항은 다음과 같습니다:

  • 기능 플래그는 기본적으로 비활성화되어야 합니다.

  • 기능 플래그는 기능 플래그 회계 필요성을 줄이기 위해 가능한 한 짧은 기간 동안 코드베이스에 남아 있어야 합니다.

  • 기능 플래그를 운영하는 사람은 기능 플래그 뒤에 있는 기능의 상태를 문서와 다른 이해 관계자에게 명확하게 전달할 책임이 있습니다.
    기능 플래그가 필요하다는 것이 분명해지면, 문제 설명을 기능 플래그 이름과 함께 업데이트하고,
    기본 설정이 켜져 있는지 꺼져 있는지 여부를 추가해야 합니다.

  • 기능 플래그를 도입하거나 상태를 업데이트하거나 기능이 안정적인 것으로 간주되어 기존 기능 플래그를 제거하는
    병합 요청에는 ~"feature flag" 레이블이 지정되어 있어야 합니다.

기능 구현이 여러 병합 요청에 걸쳐 제공되는 경우:

  1. 새 기능 플래그 만들기 - 이는 기본적으로 비활성 상태이어야 하며,
    플래그를 사용하는 첫 번째 병합 요청에서 생성해야 합니다.
    플래그는 별도로 추가되어서는 안 됩니다.

  2. 하나 이상의 병합 요청을 통해 점진적인 변경 사항을 제출하고,
    추가된 새 코드가 기능 플래그가 활성화된 경우에만 도달할 수 있도록 합니다.
    개발 중에 로컬 GDK에서 기능 플래그를 활성화 상태로 유지할 수 있습니다.

  3. 기능이 다른 팀원에 의해 테스트될 준비가 되면, 초기 문서 작성하기.
    기능 플래그의 상태에 대한 세부 정보를 포함하세요.

  4. 특정 그룹/프로젝트/사용자에 대해 기능 플래그를 활성화하고 구현에 문제가 없는지 확인하세요.
    문서가 없으면 gitlab-org/gitlab과 같은 공개 프로젝트에 기능 플래그를 활성화하지 마십시오.
    팀원 및 기여자는 공개 프로젝트에서 기능이 활성화된 것을 보면 어떻게 사용하는 지에 대한 문서를 검색할 수 있습니다.

  5. 기능이 생산 사용에 준비되면,
    자체 관리 인스턴스를 포함하여 한 병합 요청을 열어 다음을 수행합니다:

    • 최신 플래그 상태를 설명하는 문서를 업데이트합니다.
    • 변경 로그 항목 추가하기.
    • 새로운 동작을 활성화하기 위해 기능 플래그를 제거하거나, 기능 플래그를 기본적으로 활성화로 변경합니다
      (단, ops 및 beta 기능 플래그에 한정).

기능 플래그 제거가 여러 병합 요청에 걸쳐 제공되는 경우:

  1. 기능 플래그의 값 변경이 병합 요청의 유일한 변경 사항이어야 합니다.
    기능 플래그가 코드베이스에 존재하는 한, 두 상태 모두 완전히 기능해야 합니다
    (기능이 켜져 있을 때와 꺼져 있을 때).

  2. 기능 플래그에 대한 모든 언급이 제거된 후에는 레거시 코드를 제거할 수 있습니다.
    기능 플래그 롤아웃 문제의 단계를 따라야 하며,
    단계가 건너뛰어야 하는 경우에는 문제에 그 이유를 자세히 설명하는 댓글을 추가해야 합니다.

기능 플래그가 기능의 출시를 최소 한 달 동안 지연시킨다고 생각할 수 있습니다 (즉, 한 출시).
그러나 이는 사실이 아닙니다.
기능 플래그는 특정 기간 (예: 최소 한 출시) 동안 남아 있어야 할 필요가 없으며,
기능이 안정적이라고 판단될 때까지 남아 있어야 합니다.
안정적이라는 것은 GitLab.com에서 문제 없이 작동하는 것을 의미합니다.

손상된 기본 브랜치의 위험

기능 플래그는 이를 도입하는 MR에서 사용해야 합니다. 그렇지 않으면 rspec:feature-flags 작업이 기본 브랜치에서만 실행되기 때문에 손상된 기본 브랜치 시나리오가 발생합니다.

기능 플래그의 종류

예상되는 사용과 일치하는 기능 플래그 유형을 선택합니다.

gitlab_com_derisk 유형

gitlab_com_derisk 기능 플래그는 단기적인 기능 플래그로, GitLab.com 배포의 위험을 줄이는 데 사용됩니다. GitLab에서 사용되는 대부분의 기능 플래그는 gitlab_com_derisk 유형입니다.

제약 조건

  • default_enabled: true로 설정되어서는 안 됩니다. 이 유형의 기능 플래그는 GitLab.com의 위험을 줄이는 것을 목적으로 하므로, GitLab.com에서 활성화된 이후에는 코드베이스에 플래그를 유지할 필요가 없습니다. default_enabled: true는 이 유형의 기능 플래그에 대해 아무런 효과가 없습니다.
  • 최대 생명 주기: 기본 브랜치에 병합된 후 2개월
  • 문서화: 이 유형의 기능 플래그는 단기적이고 배포와 관련이 있기 때문에 GitLab의 모든 기능 플래그 페이지에 문서화할 필요가 없습니다.
  • 롤아웃 문제: 기능 플래그 롤아웃 템플릿에서 롤아웃 문제가 반드시 생성되어야 합니다.

사용법

gitlab_com_derisk 기능 플래그의 포맷은 Feature.<state>(:<dev_flag_name>)입니다.

활성화 및 비활성화하려면 GitLab Rails 콘솔에서 실행합니다:

# 인스턴스에서 활성화:
Feature.enable(:<dev_flag_name>)

# 인스턴스에서 비활성화:
Feature.disable(:<dev_flag_name>)

# 특정 프로젝트에서 활성화:
Feature.enable(:<dev_flag_name>, Project.find(<project id>))

# 특정 프로젝트에서 비활성화:
Feature.disable(:<dev_flag_name>, Project.find(<project id>))

gitlab_com_derisk 기능 플래그의 상태를 확인하려면:

# 기능 플래그가 활성화되어 있는지 확인
Feature.enabled?(:dev_flag_name)

# 기능 플래그가 비활성화되어 있는지 확인
Feature.disabled?(:dev_flag_name)

wip 유형

일부 기능은 복잡하고 여러 MR을 통해 구현해야 합니다. 완전히 구현되기 전까지는 모든 사용자에게 숨겨져 있어야 합니다. 이 경우 wip(Work In Progress, 진행 중 작업) 기능 플래그를 사용하면 실제로 기능을 사용하지 않고도 모든 변경 사항을 기본 브랜치에 병합할 수 있습니다.

기능이 완료되면, 기능 플래그 유형은 고객에게 기능이 어떻게 보여질지/문서화될지에 따라 gitlab_com_derisk 또는 beta 유형으로 변경할 수 있습니다.

제약 조건

  • default_enabled: true로 설정되어서는 안 됩니다. 필요할 경우 이 유형은 기능이 완료된 후 beta로 변경할 수 있습니다.
  • 최대 생명 주기: 기본 브랜치에 병합된 후 4개월
  • 문서화: 이 유형의 기능 플래그는 대부분 미완성 코드를 숨기기 때문에 GitLab의 모든 기능 플래그 페이지에 문서화할 필요가 없습니다.
  • 롤아웃 문제: wip 기능 플래그는 활성화되기 전에 다른 유형으로 전환되어야 하므로 롤아웃 문제는 필요하지 않을 가능성이 높습니다.

사용법 

# 기능 플래그가 활성화되어 있는지 확인
Feature.enabled?(:my_wip_flag, project)

# 기능 플래그가 비활성화되어 있는지 확인
Feature.disabled?(:my_wip_flag, project)

# 기능 플래그를 프론트엔드로 푸시
push_frontend_feature_flag(:my_wip_flag, project)

beta 유형

우리는 현재 형태로 모든 설계된 사용 사례에 대해 기능을 확장, 지원 및 유지 관리할 수 있을지 확신하지 못할 수 있습니다 (예제).

기능이 MVC로 간주하기에는 충분히 완전하지 않은 시나리오도 있습니다.

이 경우 플래그를 제공하면 엔지니어와 고객이 새로운 기능이 충분한 성능을 발휘할 때까지 비활성화할 수 있습니다.

제약 조건

  • default_enabled: 기능을 베타로 모든 사용자에게 “출시”할 수 있도록 true로 설정할 수 있으며, 확장성 문제 발생 시 비활성화할 수 있는 가능성이 있습니다. (이유로 비활성화해야 하는 경우 특정 온프레미스 설치에서만 해야 합니다.)

  • 최대 수명: 기본 브랜치에 병합된 후 6개월

  • 문서화: 이 유형의 기능 플래그는 GitLab의 모든 기능 플래그 페이지에 문서화되어야 합니다.

  • 롤아웃 이슈: 롤아웃 이슈가 생성되어야 하며 기능 플래그 롤아웃 템플릿에서 생성해야 합니다.

사용법 

# 기능 플래그가 활성화되어 있는지 확인
Feature.enabled?(:my_beta_flag, project)

# 기능 플래그가 비활성화되어 있는지 확인
Feature.disabled?(:my_beta_flag, project)

# 기능 플래그를 프론트엔드로 푸시
push_frontend_feature_flag(:my_beta_flag, project)

ops 유형

ops 기능 플래그는 GitLab 제품의 동작 측면을 제어하는 장기적인 기능 플래그입니다. 예를 들어, 성능에 영향을 미칠 수 있는 기능을 비활성화하는 기능 플래그처럼 Sidekiq 작업자 동작을 제어합니다.

이 유형을 사용할 때는 인스턴스/그룹/프로젝트/사용자 설정을 도입하지 않겠다는 의식적인 결정을 따라야 한다는 점을 기억해야 합니다.

제약 조건

  • default_enabled: 대부분의 경우 false로 설정해야 하며, 일시적인 확장성 문제를 해결하거나 운영 문제를 디버깅할 때만 활성화해야 합니다.

  • 최대 수명: 12개월

  • 문서화: 이 유형의 기능 플래그는 GitLab의 모든 기능 플래그 페이지에 문서화되어야 하며, 사용할 수 있는 상황을 설명하는 운영 매뉴얼과 관련되어야 합니다.

  • 롤아웃 이슈: 이 기능이 언제 활성화되거나 비활성화되는지 예측하기 어려운 경우 롤아웃 이슈는 필요하지 않을 수도 있습니다.

사용법 

# 기능 플래그가 활성화되어 있는지 확인
Feature.enabled?(:my_ops_flag, project)

# 기능 플래그가 비활성화되어 있는지 확인
Feature.disabled?(:my_ops_flag, project)

# 기능 플래그를 프론트엔드로 푸시
push_frontend_feature_flag(:my_ops_flag, project)

experiment 유형

experiment 기능 플래그는 GitLab.com에서 A/B 테스트를 위해 사용됩니다.

experiment 기능 플래그는 beta 기능 플래그와 동일한 기준을 준수해야 하며, 인터페이스에는 몇 가지 차이가 있습니다. 실험 기능 플래그는 실험 추적 템플릿을 사용하여 생성된 롤아웃 이슈를 가져야 합니다. 추가 정보는 실험 가이드에서 찾을 수 있습니다.

제약 조건

  • default_enabled: true로 설정되어서는 안 됩니다.

  • 최대 사용 기간: 기본 브랜치에 병합된 후 6개월

worker 유형

worker 기능 플래그는 Sidekiq 작업의 동작을 제어할 수 있는 특별한 ops 플래그로, Sidekiq 작업의 지연을 포함합니다.

worker 기능 플래그는 이름이 동적으로 생성될 수 있기 때문에 일반적으로 YAML 정의가 없을 수 있습니다. 예를 들어, run_sidekiq_jobs_AuthorizedProjectsWorker와 같습니다. worker 유형 기능 플래그를 사용하는 몇 가지 예시는 Sidekiq 작업 지연에서 찾을 수 있습니다.

(사용 중단) development 유형

development 유형은 gitlab_com_derisk, wip, 및 beta 기능 플래그 유형을 선호하여 사용 중단되었습니다.

기능 플래그 정의 및 검증

개발 중(RAILS_ENV=development) 또는 테스트 중(RAILS_ENV=test) 모든 기능 플래그 사용은 엄격하게 검증됩니다.

이 과정은 코드베이스에서 일관된 기능 플래그 사용을 보장하기 위한 것입니다. 모든 기능 플래그는 다음과 같아야 합니다:

  • 알려져 있어야 합니다. 명시적으로 정의된 기능 플래그만 사용해야 합니다(기능 플래그 유형 experiment, worker 및 undefined의 기능 플래그 제외).
  • 두 번 정의되지 않아야 합니다. FOSS 또는 EE 중 하나에 정의되어야 하며, 둘 다 정의되면 안 됩니다.
  • 정의 파일이 없는 기능 플래그의 경우 유효하고 일관된 type:을 모든 호출에 걸쳐 사용해야 합니다.
  • 소유자를 가져야 합니다.

GitLab에 알려진 모든 기능 플래그는 YAML 파일에 자가 문서화되어 있습니다:

각 기능 플래그는 여러 필드로 구성된 독립적인 YAML 파일에서 정의됩니다:

필드 필수 설명
name 예 기능 플래그의 이름.
type 예 기능 플래그의 유형.
default_enabled 예 기능 플래그의 기본 상태.
introduced_by_url 예 기능 플래그를 도입한 병합 요청의 URL.
milestone 예 기능 플래그가 생성된 마일스톤입니다.
group 예 기능 플래그를 소유하는 그룹.
feature_issue_url 아니요 원본 기능 문제의 URL.
rollout_issue_url 아니요 기능 플래그 롤아웃을 다루는 문제의 URL.
log_state_changes 아니요 기능 플래그의 상태를 기록하는 데 사용됩니다.

참고: RAILS_ENV=production에서 실행할 때 모든 검증이 생략됩니다.

새로운 기능 플래그 만들기

참고: GitLab Pages는 기능 플래그에 대해 다른 프로세스를 사용합니다.

GitLab 코드베이스는 새로운 기능 플래그 정의를 만들기 위해 전용 도구 bin/feature-flag를 제공합니다.

이 도구는 새로운 기능 플래그에 대한 다양한 질문을 한 다음, config/feature_flags 또는 ee/config/feature_flags에 YAML 정의를 생성합니다.

YAML 정의 파일이 있는 기능 플래그만 개발 또는 테스트 환경에서 사용할 수 있습니다.

$ bin/feature-flag my_feature_flag
>> 기능 플래그 유형을 지정하세요
?> beta
당신은 'beta' 유형을 선택했습니다.

>> 기능 플래그에 속하는 그룹 레이블을 다음 목록에서 지정하세요:
1. group::group1
2. group::group2
?> 2
당신은 'group::group2' 그룹을 선택했습니다.

>> 원본 기능 문제의 URL(건너뛰려면 누르세요):
?> https://gitlab.com/gitlab-org/gitlab/-/issues/435435

>> 기능 플래그를 도입하는 MR의 URL(건너뛰고 Danger가 MR에 직접 제안을 하게 하려면 누르세요):
?> https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141023

>> 기능 플래그 DRI의 사용자 이름(건너뛰려면 누르세요):
?> bob

>> 이것이 EE 전용 기능인가요(건너뛰려면 누르세요):
?> [Return]

>> 문제가 복사된 내용을 클립보드에 붙여넣는 "새 문제" 페이지를 자동으로 엽니다! 🚀
?> [Return은 자동으로 "새 문제" 페이지를 열어 문제 내용을 붙여넣기만 하면 됩니다.]

>> 롤아웃 문제의 URL(건너뛰려면 누르세요):
?> https://gitlab.com/gitlab-org/gitlab/-/issues/437162

config/feature_flags/beta/my_feature_flag.yml 생성
---
name: my_feature_flag
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/435435
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141023
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/437162
milestone: '16.9'
group: group::composition analysis
type: beta
default_enabled: false

모든 새로 도입된 기능 플래그는 기본적으로 비활성화되어야 합니다.

기능 플래그 뒤에서 개발되고 병합된 기능은 변경 로그 항목을 포함해서는 안 됩니다. 항목은 기능 플래그를 제거하는 병합 요청이나 기능 플래그의 기본 값이 활성화로 설정되는 병합 요청에 추가되어야 합니다. 기능에 데이터베이스 마이그레이션이 포함된 경우, 데이터베이스 변경 사항에 대한 변경 로그 항목을 포함해야 합니다.

참고: EE에서만 사용되는 기능 플래그를 만들려면 --ee 플래그를 추가하세요: bin/feature-flag --ee

새로운 플래그 이름 지정

새로운 기능 플래그의 이름을 정할 때 다음 가이드라인을 고려하십시오:

  • 길고 설명적인 이름이 짧고 혼란스러운 이름보다 낫습니다.

  • 이름은 스네이크 케이스(my_cool_feature_flag)로 작성하십시오.

  • 이름에 disable을 사용하지 않도록 하여 이중 부정으로 생각하거나 문서화해야 하는 상황을 피하십시오. 이름을 hide_, remove_, 또는 disallow_로 시작하는 것을 고려하십시오.

    소프트웨어 공학에서 이 문제는 “부울 변수의 부정적 이름”으로 알려져 있습니다.

    하지만 부정적인 단어를 완전히 금지할 수는 없으며,

    플래그를 기본적으로 비활성화하여 도입하거나 플래그를 뒤에 두고 기능을 제거하거나 행위자에 따라 플래그를 선택적으로 비활성화하는 데 사용할 수 있습니다.

손상된 마스터(메인) 브랜치의 위험

경고:

기능 플래그는 반드시 이를 도입하는 MR에서 사용되어야 합니다.

사용하지 않으면 master 브랜치에서만 실행되는 rspec:feature-flags 작업으로 인해 손상된 마스터 시나리오가 발생할 수 있습니다.

기능 플래그 자동 제거를 위한 .patch 파일 선택적으로 추가하기

gitlab-housekeeper는

DeleteOldFeatureFlags keep를 사용하여

기능 플래그 코드를 자동으로 제거할 수 있습니다. 이 도구는 주기적으로 실행되어 코드에서 오래된 기능 플래그를 자동으로 정리합니다.

이 도구가 코드에서 기능 플래그의 사용을 자동으로 제거하려면 기능 플래그 YAML 파일과 나란히 .patch 파일을 추가할 수 있습니다.

파일 이름은 .yml 확장자 대신 .patch 확장자를 사용하여 정확히 같은 이름이어야 합니다.

예를 들어, config/feature_flags/beta/my_feature_flag.yml에 대한 패치 파일을 만들기 위한 단계는 다음과 같습니다:

  1. 기능 플래그 my_feature_flag 사용을 제거하기 위해 코드를 로컬에서 편집합니다. 기능 플래그가 이미 활성화되어 있다고 가정하고 앞으로 롤링하는 상태입니다.

  2. git diff > config/feature_flags/beta/my_feature_flag.patch를 실행합니다.

  3. 기능 플래그 사용을 제거한 파일의 변경 사항을 취소합니다.

  4. 이 파일 config/feature_flags/beta/my_feature_flag.patch를 기능 플래그를 추가하는 브랜치에 커밋합니다.

그러면 나중에 gitlab-housekeeper가 이 패치를 적용하여 기능 플래그를 자동으로 정리할 것입니다.

모든 기능 플래그 목록

환경의 모든 기능 플래그를 Slack에 출력하기 위해 ChatOps를 사용하려면 run feature list 명령을 사용할 수 있습니다. 예를 들어:

/chatops run feature list --dev
/chatops run feature list --staging

기능 플래그 전환

기능 플래그 전환에 대한 더 많은 정보는 변경 사항 롤링 아웃을 참조하십시오.

기능 플래그 삭제

기능 플래그 삭제에 대한 더 많은 정보는 기능 플래그 정리를 참조하십시오.

기능 플래그로 개발하기

GitLab 코드베이스에서 기능 플래그를 사용하는 두 가지 주요 방법이 있습니다:

백엔드

기능 플래그 인터페이스는 lib/feature.rb에서 정의됩니다.

이 인터페이스는 기능 플래그가 활성화되었는지 비활성화되었는지 확인하는 메서드 집합을 제공합니다:

if Feature.enabled?(:my_feature_flag, project)
  # 기능 플래그가 활성화된 경우 코드를 실행합니다
else
  # 기능 플래그가 비활성화된 경우 코드를 실행합니다
end

if Feature.disabled?(:my_feature_flag, project)
  # 기능 플래그가 비활성화된 경우 코드를 실행합니다
end

구성되지 않은 기능 플래그의 기본 동작은 YAML 정의의 default_enabled:에 의해 제어됩니다.

기능 플래그에 YAML 정의가 없으면 개발 또는 테스트 환경에서는 오류가 발생하며, 프로덕션에서는 false를 반환합니다.

정의 파일이 없는 기능 플래그의 경우(오직 experiment, worker 및 undefined 유형만 허용됨), Feature.enabled? 및 Feature.disabled?를 호출할 때 해당 type:을 전달해야 합니다:

if Feature.enabled?(:experiment_feature_flag, project, type: :experiment)
  # 기능 플래그가 활성화된 경우 코드를 실행합니다
end

if Feature.disabled?(:worker_feature_flag, project, type: :worker)
  # 기능 플래그가 비활성화된 경우 코드를 실행합니다
end

경고:

애플리케이션 로드 시간에 기능 플래그를 사용하지 마십시오. 예를 들어, config/initializers/* 또는 클래스 수준에서 Feature 클래스를 사용하면 예상치 못한 오류가 발생할 수 있습니다. 이러한 오류는 기능 플래그 어댑터가 의존할 수 있는 데이터베이스가 로드 시간에 존재하지 않기 때문에 발생합니다 (특히 새 설치의 경우). 호출자에서 데이터베이스의 존재 여부를 확인하는 것은 권장되지 않으며, 일부 어댑터는 전혀 데이터베이스를 요구하지 않습니다 (예: HTTP 어댑터). 기능 플래그 설정 확인은 Feature 네임스페이스에 추상화되어야 합니다. 이 접근 방식은 기능 플래그가 변경될 때 애플리케이션을 다시 로드해야 함을 의미합니다. 따라서 SRE에게 프로덕션에서 Web/API/Sidekiq 플릿을 다시 로드하도록 요청해야 하며, 이는 변경 사항을 완전히 배포/롤백하는 데 시간이 걸립니다. 이러한 이유로 환경 변수(예: ENV['YOUR_FEATURE_NAME']) 또는 gitlab.yml을 대신 사용하십시오.

피해야 할 패턴의 예는 다음과 같습니다:

class MyClass
  if Feature.enabled?(:...)
    new_process
  else
    legacy_process
  end
end

재귀 감지

많은 기능 플래그가 있을 때, 그것들이 호출되는 위치가 항상 명확하지는 않습니다. 하나의 기능 플래그의 평가가 다른 기능 플래그의 평가를 요구하는 순환을 피하세요. 이로 인해 순환이 발생하면, 그것은 깨지고 기본 값이 반환됩니다.

이 재귀 감지가 올바르게 작동하도록 하려면, 항상 Feature::enabled?를 통해 기능 값을 접근하고, Feature::get의 저수준 사용을 피하십시오. 이런 일이 발생하면, 우리는 Feature::RecursionError 예외를 오류 추적기로 추적합니다.

프론트엔드

UI 요소에 기능 플래그를 사용할 때, 기본 백엔드 코드에도 기능 플래그를 꼭 사용해야 합니다. 이렇게 하면 기능이 활성화될 때까지 기능을 사용할 수 있는 방법이 전혀 없습니다.

ApplicationController에서 상속되는 모든 컨트롤러에서 사용할 수 있는 push_frontend_feature_flag 메서드를 사용하십시오. 이 메서드를 사용하여 기능 플래그의 상태를 노출할 수 있습니다. 예를 들면:

before_action do
  # 예를 들어 프로젝트나 사용자별로 범위를 지정하는 것을 선호합니다
  push_frontend_feature_flag(:vim_bindings, project)
end

def index
  # ...
end

def edit
  # ...
end

그런 다음 JavaScript에서 기능 플래그의 상태를 다음과 같이 확인할 수 있습니다:

if ( gon.features.vimBindings ) {
  // ...
}

JavaScript에서의 기능 플래그 이름은 항상 camelCase 형식이므로, gon.features.vim_bindings를 확인하는 것은 작동하지 않습니다.

Vue 컴포넌트에서 기능 플래그에 접근하는 방법에 대한 자세한 내용은 Vue 가이드를 참조하세요.

정의 파일이 없는 기능 플래그의 경우(오직 experiment, worker 및 undefined 유형만 허용됨), push_frontend_feature_flag 호출 시 해당 type:을 전달해야 합니다:

before_action do
  push_frontend_feature_flag(:vim_bindings, project, type: :experiment)
end

기능 배우

기능 플래그와 함께 배우를 사용하는 것이 강력히 권장됩니다. 배우는 특정 프로젝트, 그룹 또는 사용자에 대해 기능 플래그를 활성화하는 간단한 방법을 제공합니다.

이것은 디버깅을 쉽게 만들어 줍니다.

예를 들어, 배우에 따라 로그와 오류를 필터링할 수 있습니다.

이것은 또한 나머지 사용자에게 영향을 주지 않으면서 먼저 gitlab-org 또는 gitlab-com 그룹에서 기능을 활성화하는 것이 가능하게 합니다.

배우는 또한 기능의 비율 롤아웃을 쉽게 할 수 있는 방법을 제공합니다.

1% 롤아웃이 특정 배우를 위해 기능을 활성화하면, 그 배우는 10%, 50%, 100%에서 계속해서 기능이 활성화됩니다.

GitLab은 다음 기능 플래그 배우를 지원합니다:

  • User 모델
  • Project 모델
  • Group 모델
  • 현재 요청

배우는 Feature.enabled? 호출의 두 번째 매개변수입니다. 예를 들어:

Feature.enabled?(:feature_flag, project)

include FeatureGate가 포함된 모델은 .actor_from_id 클래스 메소드를 가집니다.

모델의 ID가 있고 기능 플래그 상태를 확인하는 것 외에는 모델이 필요하지 않은 경우, 데이터베이스 쿼리를 통해 모델을 검색하지 않고 기능 플래그 상태를 확인하기 위해 .actor_from_id를 사용할 수 있습니다.

# 나쁜 -- 불필요한 쿼리가 실행됩니다.
Feature.enabled?(:feature_flag, Project.find(project_id))

# 좋은 -- 프로젝트에 대한 쿼리가 없습니다.
Feature.enabled?(:feature_flag, Project.actor_from_id(project_id))

# 좋은 -- 기능 플래그 체크 후 프로젝트 모델이 사용됩니다.
project = Project.find(project_id)
return unless Feature.enabled?(:feature_flag, project)
project.update!(column: value)

ChatOps를 사용하여 기능 플래그를 활성화하고 비활성화하는 방법에 대한 자세한 내용은 ChatOps를 사용하여 기능 플래그를 활성화 및 비활성화하기를 참조하세요.

플래그 상태는 그룹의 하위 그룹이나 프로젝트에서 상속되지 않습니다.

전체 그룹 계층에 대해 플래그 상태가 일관되도록 하려면 최상위 그룹을 배우로 사용하는 것을 고려하세요.

이 그룹은 모든 그룹이나 프로젝트에서 #root_ancestor를 호출하여 찾을 수 있습니다.

Feature.enabled?(:feature_flag, group.root_ancestor)

배우 유형 혼합

일반적으로 특정 기능 플래그에 대해 Feature.enabled?의 모든 호출에서 하나의 유형의 배우만 사용하는 것이 좋으며, 서로 다른 배우 유형을 혼합하지 않아야 합니다.

배우 유형 혼합은 버그를 유발할 수 있는 방식으로 기능이 비일관되게 활성화되거나 비활성화되도록 할 수 있습니다.

예를 들어, 컨트롤러 수준에서 그룹 배우를 사용하여 플래그를 확인하고 서비스 수준에서 사용자 배우를 사용하여 확인하면, 기능은 같은 요청의 서로 다른 시점에서 활성화되거나 비활성화될 수 있습니다.

일부 상황에서는 결과가 일관되지 않게 되지 않을 것이라는 것을 알고 있다면 배우 유형을 혼합하는 것이 안전합니다.

예를 들어, 웹후크는 그룹이나 프로젝트와 연결될 수 있으며, 따라서 웹후크에 대한 기능 플래그는 이 기능을 사용하여 그룹과 프로젝트 웹후크에 대해 동일한 기능 플래그를 사용하여 롤아웃할 수 있습니다.

다른 배우 유형을 사용해야 하고 상황에서 안전하게 혼합할 수 없는 경우 각 배우 유형에 대해 별도의 플래그를 사용해야 합니다. 예를 들어:

Feature.enabled?(:feature_flag_group, group)
Feature.enabled?(:feature_flag_user, user)

인스턴스 배우

경고: 인스턴스 전체 기능 플래그는 기능이 전체 인스턴스에 연결되어 있을 때만 사용해야 합니다. 항상 다른 배우를 우선시하세요.

일부 경우, 배우에 따라 설정되지 않고 전체 인스턴스에 대해 기능 플래그가 활성화되기를 원할 수 있습니다.

훌륭한 예시는 관리 설정입니다.

여기서는 그룹이나 프로젝트에 따라 기능 플래그를 활성화하는 것이 불가능합니다.

사용자 배우는 혼란을 초래합니다.

기능 플래그가 관리자가 아닌 사용자에게 활성화될 수 있지만, 사용자에게는 비활성화될 수 있습니다.

대신, :instance 기호를 두 번째 인수로 사용하여 Feature.enabled?를 사용할 수 있으며, 이는 GitLab 인스턴스로 정리됩니다.

Feature.enabled?(:feature_flag, :instance)

현재 요청 액터

시간 비율 롤아웃을 사용하는 것은 권장되지 않으며, 각 호출이 일관되지 않은 결과를 반환할 수 있습니다.

현재 요청을 액터로 사용하는 것이 좋습니다.

# 나쁨
Feature.enable_percentage_of_time(:feature_flag, 40)
Feature.enabled?(:feature_flag)

# 좋음
Feature.enable_percentage_of_actors(:feature_flag, 40)
Feature.enabled?(:feature_flag, Feature.current_request)

현재 요청을 액터로 사용할 때, 기능 플래그는 요청의 맥락 내에서 같은 값을 반환해야 합니다.

현재 요청 액터는 SafeRequestStore를 사용하여 구현되므로, 다음 내에서 일관된 기능 플래그 값을 가져야 합니다:

  • Rack 요청
  • Sidekiq 작업 실행
  • ActionCable 작업 실행

기존 기능을 시간 비율에서 현재 요청 액터로 마이그레이션하려면, 새로운 기능 플래그를 만드는 것이 좋습니다.

이는 기존 percentage_of_time 값, 코드 변경 배포, 및 percentage_of_actors 사용 전환 간의 타이밍을 제어하기가 어렵기 때문입니다.

프로덕션에서 검증하기 위한 액터 사용

경고: 프로덕션을 테스트 환경으로 사용하는 것은 권장되지 않습니다. 프로덕션 준비가 되지 않은 기능을 테스트하기 위해 우리 테스트 환경을 사용하세요.

스테이징 환경은 프로덕션과 유사한 환경에서 기능을 테스트할 수 있는 방법을 제공하지만, 프로덕션 환경에 특정한 성능 메트릭의 전후 비교를 허용하지 않습니다. 프로덕션에서 개발 기능 플래그가 활성화된 프로젝트를 갖고 있으면, Sitespeed 보고서와 같은 도구가 기능 플래그에 따라 새로운 코드의 메트릭을 드러내는 데 유용할 수 있습니다.

이 접근법은 Sitespeed에서 구형 코드베이스를 이미 추적하고 있는 경우 더욱 유용하여, 기능 플래그의 롤아웃 전후 성능을 정확하게 비교할 수 있게 해줍니다.

액터로서 추가 객체 사용 가능

액터를 기반으로 한 기능 게이트를 사용하려면, 모델이 flipper_id에 응답해야 합니다. 예를 들어, Foo 모델을 활성화할 경우:

class Foo < ActiveRecord::Base
  include FeatureGate
end

오직 FeatureGate를 포함하거나 flipper_id 메서드를 노출하는 모델만 Feature.enabled?의 액터로 사용할 수 있습니다.

라이센스 기능에 대한 기능 플래그

라이센스 기능 이름과 같은 이름을 가진 기능 플래그를 사용할 수 없으며, 이는 이름 충돌을 초래하기 때문입니다. 이는 광범위하게 논의되고 제거되었습니다 혼란을 초래할 수 있습니다.

라이센스 기능을 확인하려면, 다른 이름 아래에 전용 기능 플래그를 추가하고 이를 명시적으로 확인하십시오. 예를 들어:

Feature.enabled?(:licensed_feature_feature_flag, project) &&
  project.feature_available?(:licensed_feature)

기능 그룹

기능 그룹은 lib/feature.rb(의 .register_feature_groups 메서드)에 정적으로 정의되어야 하지만, 그 구현은 동적일 수 있습니다(예: DB 쿼리).

lib/feature.rb에 정의된 후에는 feature_group 매개변수를 통해 특정 기능 그룹에 대한 기능을 활성화할 수 있습니다.

사용 가능한 기능 그룹은 다음과 같습니다:

그룹 이름 범위 설명
gitlab_team_members 사용자 gitlab-com의 회원인 사용자에게 기능을 활성화합니다.

기능 그룹은 그룹 이름을 통해 활성화할 수 있습니다:

Feature.enable(:feature_flag_name, :gitlab_team_members)

로컬 기능 플래그 제어

Rails 콘솔에서

Rails 콘솔(rails c)에서 다음 명령어를 입력하여 기능 플래그를 활성화할 수 있습니다:

Feature.enable(:feature_flag_name)

유사하게, 다음 명령어는 기능 플래그를 비활성화합니다:

Feature.disable(:feature_flag_name)

특정 게이트에 대해 기능 플래그를 활성화할 수도 있습니다:

Feature.enable(:feature_flag_name, Project.find_by_full_path("root/my-project"))

Rails 콘솔에서 수동으로 기능 플래그를 활성화하거나 비활성화할 때, 기본값이 덮어쓰여집니다.

이는 플래그의 default_enabled 속성을 변경할 때 혼란을 초래할 수 있습니다.

기능 플래그를 기본 상태로 재설정하려면:

Feature.remove(:feature_flag_name)

브라우저에서

http://gdk.test:3000/rails/features에 접속하여 기능 플래그를 로컬로 관리하세요.

로깅

기능 플래그의 사용 및 상태는 다음 중 하나일 경우 로깅됩니다:

  • 기능 플래그 정의에서 log_state_changes가 true로 설정되어 있는 경우.
  • milestone이 현재 GitLab 버전과 같거나 더 큰 마일스톤을 참조하는 경우.

기능 플래그의 상태가 로깅될 때는 Kibana에서 "json.feature_flag_states": "feature_flag_name:1" 또는 "json.feature_flag_states": "feature_flag_name:0" 조건을 사용하여 식별할 수 있습니다.

예시를 여기 링크에서 확인할 수 있습니다.

참고: 기능 플래그의 상태를 기록하는 요청은 20%만 해당됩니다. 이는 feature_flag_state_logs 기능 플래그로 제어됩니다.

변경 로그

기능이 최종 사용자에 의해 직접(예: 기능 사용 가능성) 또는 간접적으로(예: 백그라운드 작업, 성능 개선 또는 데이터베이스 마이그레이션 업데이트 활용 가능성) 접근할 수 없는 경우 변경 로그를 도입하는 것을 피하고자 합니다.

  • 데이터베이스 마이그레이션은 항상 최종 사용자가 간접적으로 접근할 수 있으므로, 자가 관리 고객은 업그레이드 전에 데이터베이스 변경 사항을 인지해야 합니다. 따라서, 변경 로그 항목이 있어야 합니다.
  • 기본적으로 비활성화된 기능 플래그 뒤에 있는 변경 사항은 변경 로그 항목이 없어야 합니다.
  • 기본적으로 활성화된 기능 플래그 뒤에 있는 변경 사항은 변경 로그 항목이 있어야 합니다.
  • 기능 플래그 자체의 변경(플래그 제거, 기본 활성화 설정)은 변경 로그 항목이 있어야 합니다.

흐름도를 사용하여 변경 로그 항목 유형을 결정하십시오.

flowchart LR FDOFF(플래그가 현재<br>'default: off' 상태입니다) FDON(플래그가 현재<br>'default: on' 상태입니다) CDO{변경:<br>'default: on'} ACF(추가됨 / 변경됨 / 수정됨 / '...') RF{플래그 제거} RF2{플래그 제거} RC(제거됨 / 변경됨) OTHER(기타) FDOFF -->CDO-->ACF FDOFF -->RF RF-->|새 코드 유지?| ACF RF-->|구 코드 유지?| OTHER FDON -->RF2 RF2-->|구 코드 유지?| RC RF2-->|새 코드 유지?| OTHER
  • 기능 플래그에 대한 변경 로그는 기능을 설명해야 하며, 플래그를 설명하지 않아야 합니다. 단, 기본 활성화 기능 플래그가 새 코드를 유지하면서 제거된 경우(위 흐름도의 기타)는 제외입니다.
  • 기능 플래그는 버그 수정이나 유지 관리 작업의 롤아웃에도 사용할 수 있습니다. 이 경우, 변경 로그는 관련되어야 하며, 예를 들어 'fixed' 또는 '기타'와 같이 작성되어야 합니다.

테스트의 기능 플래그

코드베이스에 기능 플래그를 도입하면 테스트해야 하는 추가 코드 경로가 생성됩니다.

기능 플래그에 의해 영향을 받는 모든 코드에 대해 활성화 및 비활성화 모두 자동화된 테스트를 포함하는 것을 강력히 권장합니다.

기능이 제대로 작동하는지 확인하기 위해서입니다. 두 상태에 대해 자동화된 테스트가 포함되지 않은 경우, 배포 전에 테스트되지 않은 코드 경로와 연관된 기능을 수동으로 테스트해야 합니다.

테스트 환경을 사용할 때 모든 기능 플래그는 기본적으로 활성화되어 있습니다.

플래그는 spec/spec_helper.rb 파일에서 기본적으로 비활성화할 수 있습니다.

플래그를 비활성화해야 하는 이유를 설명하는 주석을 인라인으로 추가하세요. 가능하다면 참조를 위한 이슈 URL을 첨부할 수도 있습니다.

경고: 이는 엔드 투 엔드(QA) 테스트에는 적용되지 않습니다. 기본적으로 기능 플래그를 활성화하지 않습니다. 엔드 투 엔드 테스트에서 기능 플래그를 사용하는 데는 다른 프로세스가 있습니다.

테스트에서 기능 플래그를 비활성화하려면 stub_feature_flags 헬퍼를 사용하세요. 예를 들어, 테스트에서 ci_live_trace 기능 플래그를 전역적으로 비활성화하려면:

stub_feature_flags(ci_live_trace: false)

Feature.enabled?(:ci_live_trace) # => false

두 경로를 모두 테스트하는 일반적인 패턴은 다음과 같습니다:

it 'ci_live_trace works' do
  # 테스트는 기본적으로 ci_live_trace가 활성화 되어 있다고 가정
  Feature.enabled?(:ci_live_trace) # => true
end

context 'when ci_live_trace is disabled' do
  before do
    stub_feature_flags(ci_live_trace: false)
  end

  it 'ci_live_trace does not work' do
    Feature.enabled?(:ci_live_trace) # => false
  end
end

기능 플래그가 일부 사용자에게만 활성화되도록 테스트를 설정하려면 헬퍼에 전달된 옵션에서 이를 명시할 수 있습니다. 예를 들어, 특정 프로젝트에 대해 ci_live_trace 기능 플래그를 활성화하려면:

project1, project2 = build_list(:project, 2)

# 기능은 project1에 대해서만 활성화됩니다.
stub_feature_flags(ci_live_trace: project1)

Feature.enabled?(:ci_live_trace) # => false
Feature.enabled?(:ci_live_trace, project1) # => true
Feature.enabled?(:ci_live_trace, project2) # => false

FlipperGate의 동작은 다음과 같습니다:

  1. 특정 사용자에 대해 오버라이드를 활성화할 수 있습니다.
  2. 특정 사용자에 대해 오버라이드를 비활성화(제거)할 수 있으며, 기본 상태로 돌아갑니다.
  3. 특정 사용자를 명시적으로 비활성화했다고 모델링하는 방법은 없습니다.
Feature.enable(:my_feature)
Feature.disable(:my_feature, project1)
Feature.enabled?(:my_feature) # => true
Feature.enabled?(:my_feature, project1) # => true

Feature.disable(:my_feature2)
Feature.enable(:my_feature2, project1)
Feature.enabled?(:my_feature2) # => false
Feature.enabled?(:my_feature2, project1) # => true

have_pushed_frontend_feature_flags

have_pushed_frontend_feature_flags를 사용하여 push_frontend_feature_flag가 HTML에 기능 플래그를 추가했는지 테스트합니다.

예를 들면,

stub_feature_flags(value_stream_analytics_path_navigation: false)

visit group_analytics_cycle_analytics_path(group)

expect(page).to have_pushed_frontend_feature_flags(valueStreamAnalyticsPathNavigation: false)

stub_feature_flags 대 Feature.enable*

테스트 환경에서 기능 플래그를 활성화하는 데는 stub_feature_flags를 사용하는 것이 좋습니다. 이 방법은 간단한 사용 사례를 위한 간단하고 잘 설명된 인터페이스를 제공합니다.

그러나 때때로 기능 플래그의 비율 롤아웃과 같은 더 복잡한 동작을 테스트해야 할 경우가 있습니다. 이는 .enable_percentage_of_time 또는 .enable_percentage_of_actors를 사용하여 수행할 수 있습니다:

# 좋음: 기능은 명시적으로 비활성화되어야 하며 정의되지 않으면 기본적으로 활성화됩니다
stub_feature_flags(my_feature: false)
stub_feature_flags(my_feature: true)
stub_feature_flags(my_feature: project)
stub_feature_flags(my_feature: [project, project2])

# 나쁨
Feature.enable(:my_feature_2)

# 좋음: my_feature를 50%의 시간 동안 활성화합니다
Feature.enable_percentage_of_time(:my_feature_3, 50)

# 좋음: my_feature를 50%의 사용자/게이트/항목에 대해 활성화합니다
Feature.enable_percentage_of_actors(:my_feature_4, 50)

각 기능 플래그는 정의된 상태가 테스트 실행 시간 동안 지속됩니다:

Feature.persisted_names.include?('my_feature') => true
Feature.persisted_names.include?('my_feature_2') => true
Feature.persisted_names.include?('my_feature_3') => true
Feature.persisted_names.include?('my_feature_4') => true

스텁 액터

특정 액터에 대해서만 기능 플래그를 활성화하려면, 해당 액터의 표현을 스텁할 수 있습니다. Feature.enabled? 및 Feature.disabled?에 대한 인자로 전달되는 게이트는 FeatureGate를 포함하는 객체여야 합니다.

사양에서는 stub_feature_flag_gate 메서드를 사용하여 사용자 정의 액터를 빠르게 생성할 수 있습니다:

gate = stub_feature_flag_gate('CustomActor')

stub_feature_flags(ci_live_trace: gate)

Feature.enabled?(:ci_live_trace) # => false
Feature.enabled?(:ci_live_trace, gate) # => true

테스트에서 기능 플래그 엔진 제어

테스트 환경의 Flipper 엔진은 메모리 모드 Flipper::Adapters::Memory에서 작동합니다.

production 및 development 모드는 Flipper::Adapters::ActiveRecord를 사용합니다.

사용 중인 모드가 Flipper::Adapters::Memory인지 ActiveRecord인지 제어할 수 있습니다.

stub_feature_flags: true (기본값 및 권장)

이 모드에서는 Flipper가 Flipper::Adapters::Memory를 사용하도록 구성되어 있으며, 모든 기능 플래그를 기본적으로 활성화하고 최초 사용 시 지속됩니다.

기능 플래그에 따라 동작이 특정하지 않은 컨텍스트에서 테스트되지 않도록 해야 합니다.

stub_feature_flags: false

이 모드는 메모리 스텁한 플리퍼를 비활성화하고, production 및 development에서 사용되는 Flipper::Adapters::ActiveRecord를 사용합니다.

이 모드는 Flipper가 ActiveRecord와 상호 작용하는 방면을 실제로 테스트하고자 할 때만 사용해야 합니다.

엔드 투 엔드 (QA) 테스트

엔드 투 엔드 (QA) 테스트에서 기능 플래그를 전환하는 방식은 다릅니다. 엔드 투 엔드 테스트 프레임워크는 Rails 또는 데이터베이스에 직접 액세스할 수 없으므로 Flipper를 사용할 수 없습니다. 대신, 공용 API를 사용합니다. 각 엔드 투 엔드 테스트는 테스트 중에 기능 플래그를 활성화하거나 비활성화할 수 있습니다. 또는, GitLab 저장소의 qa 디렉토리에서 실행할 때 여러 테스트 전에 기능 플래그를 활성화하거나 비활성화할 수 있습니다. 또는 GitLab QA을 통해 테스트를 실행하는 경우 기능 플래그를 활성화하거나 비활성화할 수 있습니다.

앞서 언급한 것처럼, 엔드 투 엔드 테스트에서는 기능 플래그가 기본적으로 활성화되지 않습니다.

이것은 엔드 투 엔드 테스트가 소스 코드에 구현된 기본 상태로 기능 플래그를 실행하거나, 테스트 중인 GitLab 인스턴스에서 기능 플래그가 현재 상태로 실행된다는 것을 의미합니다. 테스트가 기능 플래그를 명시적으로 활성화/비활성화하도록 작성되지 않는 한입니다.

Staging 또는 GitLab.com에서 기능 플래그가 변경되면, 해당 변경 사항이 기능 플래그와 관련된 실패인지 보다 쉽게 판단할 수 있도록 파이프라인 triage DRI에게 알리기 위해 #e2e-run-staging 또는 #e2e-run-production 채널에 슬랙 메시지가 게시됩니다. 그러나 변경 작업을 수행하는 경우 기능 플래그가 활성화된 상태에서 엔드 투 엔드 테스트가 통과하는지 확인하여 예기치 않은 실패를 방지할 수 있습니다.

Sidekiq 워커 동작 제어하기: 기능 플래그

worker 형식의 기능 플래그를 사용하여 Sidekiq 워커의 동작을 제어할 수 있습니다.

Sidekiq 작업 연기

비활성화할 경우, run_sidekiq_jobs_{WorkerName} 형식의 기능 플래그는 워커의 실행을 지연시켜 작업을 나중에 예약합니다. 이 기능 플래그는 모든 워커에 대해 기본적으로 활성화되어 있습니다.

사건 발생 시에 워커 인스턴스의 논란이 되는 동작이 인프라 자원(예: 데이터베이스 및 데이터베이스 연결 풀)을 포화시키는 경우, 작업을 연기하는 것은 유용할 수 있습니다.

구현은 SkipJobs Sidekiq 서버 미들웨어에서 확인할 수 있습니다.

note
기능 플래그가 비활성화되어 있는 한, 작업은 무기한 연기됩니다. 워커가 처리 계속 가능하다고 판단되면 기능 플래그를 제거하는 것이 중요합니다.

false로 설정할 경우, 100%의 작업이 연기됩니다. 처리를 다시 시작하려면 시간 비율 롤아웃을 사용할 수 있습니다. 예를 들어:

# 어떤 작업도 실행하지 않고, 모든 100% 작업을 연기
/chatops run feature set run_sidekiq_jobs_SlowRunningWorker false

# 10%의 작업만 실행하고, 90%의 작업을 연기
/chatops run feature set run_sidekiq_jobs_SlowRunningWorker 10

# 50%의 작업을 실행하고, 50%의 작업을 연기
/chatops run feature set run_sidekiq_jobs_SlowRunningWorker 50

# 모든 작업을 정상적으로 실행
/chatops run feature delete run_sidekiq_jobs_SlowRunningWorker

Sidekiq 작업 삭제

작업 연기 대신, drop_sidekiq_jobs_{WorkerName} 기능 플래그를 활성화하여 작업을 완전히 삭제할 수 있습니다. 향후 작업이 처리될 필요가 없다고 확신할 때 이 기능 플래그를 사용하십시오.

# 모든 작업 삭제
/chatops run feature set drop_sidekiq_jobs_SlowRunningWorker true

# 작업을 정상적으로 처리
/chatops run feature delete drop_sidekiq_jobs_SlowRunningWorker
note
기능 플래그(drop_sidekiq_jobs_{WorkerName})는 연기 기능 플래그(run_sidekiq_jobs_{WorkerName})보다 우선합니다. 즉, drop_sidekiq_jobs가 활성화되고 run_sidekiq_jobs가 비활성화되면 작업이 완전히 삭제됩니다.