ChatOps를 사용하여 기능 플래그를 활성화하고 비활성화하십시오

이 문서는 GitLab 제품의 개발에 기여하는 방법을 설명합니다. 개인 애플리케이션에서 기능 플래그를 사용하여 기능을 표시하거나 숨기려면 대신 기능 플래그 정보를 봐주세요.

GitLab에서 제공하는 스테이징 및 프로덕션과 같은 시스템에서 기능 플래그 뒤의 기능을 켜거나 끄려면 ChatOps 봇에 액세스해야 합니다. ChatOps 봇 현재 ops 인스턴스에서 실행 중이며, 이는 GitLab.com이나 dev.gitlab.org와는 다릅니다.

액세스를 요청하려면 ChatOps 문서를 따르세요.

프로젝트에 추가되면 액세스가 전파되었는지 확인하려면 다음을 실행하세요:

/chatops run feature --help

변경 사항 롤아웃

환경으로 변경 사항이 배포되면 사용자에게 기능을 시작할 시간입니다. 변경 사항을 전개하는 정확한 프로시저는 변경 사항마다 달라질 수 있으므로 일반적으로 변경 사항을 증분적으로 전개하는 것을 권장합니다. 또한, 코드를 배포하기 전에 테스트하는 것을 권합니다. 이렇게 함으로써 기능의 전개를 배포와 분리하여 두 가지의 영향을 개별적으로 측정할 수 있도록 만듭니다.

GitLab 기능 라이브러리(Fipper 사용) (Flipper) 및 기능 플래그 프로세스 가이드에서 설명된 바에 따르면 사용자에게 설정된 시간 비율로 변경을 전개하는 것을 지원합니다. 이것은 다시 GitLab ChatOps를 사용하여 제어할 수 있습니다.

기능 플래그 명령의 최신 목록은 소스 코드를 참조하세요. 해당 파일의 모든 예시는 반드시 /chatops run로 시작해야 함에 유의하세요.

“Whoops! This action is not allowed. This incident will be reported.”라는 오류가 발생하면 Slack 계정이 기능 플래그를 변경할 수 없거나 액세스할 수 없는 것입니다.

사전 프로덕션 테스트를 위한 기능 활성화

기능을 전개하는 첫 번째 단계로 staging.gitlab.com 및 dev.gitlab.org에서 기능을 활성화해야 합니다.

이 두 환경은 서로 다른 스코프를 갖고 있습니다. dev.gitlab.org는 내부 GitLab Inc. 트래픽을 갖는 프로덕션 CE 환경이며 일부 개발 및 기타 관련 작업에 사용됩니다. staging.gitlab.com은 GitLab.com 데이터베이스 및 리포지토리의 작은 하위 집합을 가지고 있으며 정기적인 트래픽이 없습니다. 스테이징은 EE 인스턴스이며 GitLab.com에서 해당 기능이 어떻게 보이고 작동할지에 대한 (매우) 미묘한 추정을 제공할 수 있습니다. 두 인스턴스 모두 Sentry와 연결되어 있으므로 기능을 활성화한 후 해당 프로젝트에서 예외를 확인하세요.

전 제품 환경에 대해서는 가시성을 향상시키기 위해 #staging, #production, 또는 #chatops-ops-test에서 명령을 실행하는 것이 강력히 권장됩니다.

시간 비율로 기능 플래그 활성화

기능을 25%의 시간 동안 활성화하려면 Slack에서 다음을 실행하세요:

/chatops run feature set new_navigation_bar 25 --random --dev
/chatops run feature set new_navigation_bar 25 --random --staging

시간 비율 기능 플래그는 배우 주체의 백분율로 대체되었습니다. 시간 비율 기능 플래그를 사용하는 결과를 이해하는 경우에만 --ignore-random-deprecation-check를 사용하여 강제할 수 있습니다.

GitLab.com에서 기능 활성화

기능이 성공적으로 사전 프로덕션 환경에서 활성화되고 안전하고 작동하는 것으로 확인되면 변경 사항을 GitLab.com(프로덕션)에 전개할 수 있습니다.

기능이 사라진 경우 플래그를 활성화하지 마세요.

변경 내용 통보

GitLab.com에서의 기능 플래그 변경 사항은 회사의 부분과 통신해야 할 수 있습니다. 책임 있는 개발자는 이것이 필요한지 및 적절한 통신 수준을 결정해야 합니다. 이것은 기능 및 어떤 종류의 영향을 미칠 수 있는지에 따라 다릅니다.

지침:

#support_gitlab-com에 미리 알리는 것을 고려하세요. 사용자 경험에 어떠한 부수 효과가 있는 경우 해당 기능을 완화하고 비활성화할 수 있습니다.
변경 관리 발급을 위한 요구 사항을 충족하는 기능의 경우 진행 가이드라인별로 변경 관리 이슈를 만드세요.
간단하고 저위험성, 쉽게 복구 가능한 기능의 경우, 프로덕션에서 기능을 활성화하세요.
특정 그룹이나 프로젝트를 위해 기능 플래그를 전환하기 위한 지원 요청의 경우 지원 워크플로를 따르세요.

롤아웃 중 선택할 백분율 지침

기능 플래그 롤아웃 시 어떤 백분율을 선택할지 결정하는 것은 다른 요소에 따라 달라집니다. 예를 들어 다음과 같습니다:

기능 플래그가 자주 확인되어 롤아웃을 계속 진행할 수 있는 충분한 정보를 수집할 수 있는지 여부
기능에 문제가 발생하면 영향을 받는 요청 또는 고객이 몇 명인지
기능에 문제가 발생하면 롤아웃에 영향을 받을 수 있는 다른 공개 기능이 있는지
기능 플래그를 롤아웃함으로써 성능 저하가 발생할 가능성

다양한 유형의 기능 플래그에 대해 롤아웃을 고려하는 방법을 몇 가지 예를 들어 살펴보겠습니다.

A. 하루에 몇 번 실행되는 작업을 위한 기능 플래그

예를 들어, 하루에 몇 번 실행되는 새로운 기능을 출시할 경우, 예를 들어, 매일 또는 매 시간 cron 작업에서 실행되는 새로운 기능을 컨트롤하는 기능 플래그가 포함될 수 있습니다. 예를 들어, cron 작업을 위한 데이터베이스 쿼리 재작성. 이 경우에는 25% 이하의 백분율로 기능 플래그를 출시하면 롤아웃을 계속 진행할지 여부에 대한 느린 피드백을 제공할 수 있습니다. 또한, cron 작업이 실패하면 재시도됩니다. 따라서 실패 시의 결과는 그다지 크지 않을 것입니다. 이 경우, 25% 또는 50%의 백분율로 출시하는 것이 적절합니다.

그러나 기능 플래그 확인 결과를 로거의 로그에 기록해야 합니다. 로깅의 최적의 방법을 확인하세요.

B. 하루에 수백 번 또는 수천 번 실행되는 작업을 위한 기능 플래그

새롭게 도입한 기능 또는 변경이 Sidekiq 작업에서 실행되는 것보다 고객과 더 많은 상호 작용을 할 수 있습니다. 그러나 자주 실행되지 않을 수 있습니다. 이 경우, 계속 진행할지 여부를 파악하기 위해 결과를 수집할 수 있을 만큼 충분히 높은 백분율을 선택할 수 있습니다. 여기서는 5% 또는 10%를 선택하는 것을 고려할 수 있으며, 동시에 오류를 모니터링하거나 사용자에게 반환된 500 상태를 확인할 수 있습니다.

그러나 롤아웃을 계속하고 백분율을 높이면서 기능의 성능 영향을 고려해야 합니다. Grafana의 지연 시간: Apdex 및 오류 비율 대시보드를 모니터링할 수 있습니다.

C. 앱의 핵심에서 실행되는 작업을 위한 기능 플래그

때로는 GitLab 애플리케이션의 모든 측면에 영향을 줄 수 있는 새로운 변경 사항이 있습니다. 예를 들어, User, Project, 또는 Namespace와 같이 핵심 모델 중 하나의 데이터베이스 쿼리를 변경하는 경우입니다. 이 경우, 1%의 요청을 위해 기능을 출시하거나 변화 요청을 통해 심지어 그것보다 더 적게 출시하는 것이 어떤 사건도 발생하지 않도록 강력히 권장됩니다. 변경 사항의 영향이 클 경우 날 것의 요청이 얼마나 영향을 받을 수 있는지 추정해야 합니다. 이를 위해서는 데이터베이스 쿼리를 추적하여 분석해야 합니다. 여기의 지침을 참고하세요.

만약 롤아웃이 예상대로 진행되지 않는다면 영향을 받을 수 있는 합리적인 수의 요청 또는 사용자 수를 계산하는 것
(1) 및 (2)에서 수집한 숫자를 기반으로 출시할 기능 플래그의 합리적인 백분율을 계산하는 것, 예시 확인
출시된 기능 플래그의 롤아웃 이슈에 대한 조사 결과를 명확히 전달하는 것

D. 기능 플래그 출시의 알려지지 않은 영향

만약 사용할 백분율을 확신할 수 없다면, 안전한 권장 옵션을 선택하고 다음과 같은 백분율을 선택하세요:

1%
10%
25%
50%
75%
100%

각 단계 사이에 잠시 기다려서 https://dashboards.gitlab.net의 적절한 그래프를 모니터링해야 합니다. 기다릴 정확한 시간은 달라질 수 있습니다. 일부 기능의 경우 몇 분이면 충분할 수 있지만, 다른 기능의 경우 몇 시간 또는 심지어 몇 일을 기다릴 수도 있습니다. 이부분은 완전히 사용자의 선택이지만 잠재적인 문제가 발생할 것으로 예상된다면 팀과 제조팀에 명확히 전달해야 합니다.

프로세스

기능 플래그 롤아웃을 활성화할 때 시스템은 자동으로 ChatOps 명령이 성공하지 못하도록 차단됩니다. 활성 “severity::1” 또는 “severity::2” 사건 또는 진행 중인 변경 사항이 있는 경우입니다. 예를 들어:

/chatops run feature set gitaly_lfs_pointers_pipeline true

- Production checks fail!
- active incidents

  2021-06-29 Canary deployment failing QA tests

기능 플래그를 활성화하기 전에 Production Change Lock periods를 위반하지 않고 Feature flags and the Change Management Process를 준수하는지 확인하세요.

다음 /chatops 명령은 Slack #production 채널에서 실행되어야 합니다.

기능을 활성화할 때, 첫 번째 /chatops 명령의 Slack 스레드에 관련 기능 플래그 롤아웃 이슈에 링크를 걸어 다른 사람들이 필요한 경우 변경 사항을 이해할 수 있도록 합니다.

Slack에서 시간의 25%에 대해 기능을 활성화하려면 다음을 실행하세요:

/chatops run feature set new_navigation_bar 25 --random

참고: 현재 시간의 백분율은 percentage of actors를 선호하여 사용되는 기능 플래그의 시간의 백분율로 대체됩니다. 시간의 백분율 기능 플래그를 사용할 후속행동을 이해한다면, --ignore-random-deprecation-check를 사용하여 강제로 사용할 수 있습니다.

이는 다음 공식에 따라 기능 플래그를 true로 설정합니다:

feature_flag_state = rand < (25 / 100.0)

이는 new_navigation_bar를 기능의 이름으로 사용하여 GitLab.com의 기능을 활성화합니다. 이 명령은 총 사용자 중 25%에 대해 기능을 활성화하지는 않습니다. 대신, 기능을 enabled?로 확인할 때 전체 사용자 중 25%의 시간 동안 true를 반환합니다.

사용자, 프로젝트 또는 그룹과 같은 다양한 참여자에게 25%의 시간 동안 기능을 활성화하려면 Slack에서 다음을 실행하세요:

/chatops run feature set some_feature 25 --actors

이것은 다음 공식에 따라 기능 플래그를 true로 설정합니다:

feature_flag_state = Zlib.crc32("some_feature<Actor>:#{actor.id}") % (100 * 1_000) < 25 * 1_000
# 여기서 <Actor>:는 `User`, `Group`, `Project`이고, actor는 인스턴스입니다

개발 중에 기능의 성격에 따라 참여자 선택을 해야 합니다.

사용자 중심 기능의 경우:

Feature.enabled?(:feature_cool_avatars, current_user)

그룹 또는 네임스페이스 수준의 기능의 경우:

Feature.enabled?(:feature_cooler_groups, group)

프로젝트 수준의 기능의 경우:

Feature.enabled?(:feature_ice_cold_projects, project)

현재 요청의 경우:

Feature.enabled?(:feature_ice_cold_projects, Feature.current_request)

기능 게이트도 참여자를 기반으로 할 수 있으며, 예를 들어 기능은 먼저 gitlab 프로젝트에 대해 활성화될 수 있습니다. 프로젝트는 --project 플래그를 제공하여 전달됩니다:

/chatops run feature set --project=gitlab-org/gitlab some_feature true

특정 사용자를 위해 기능 플래그를 활성화하려면 --user 옵션을 사용할 수 있습니다:

/chatops run feature set --user=myusername some_feature true

내부적으로 먼저 피드백을 수집하려면, 사용자 범위의 기능 플래그를 gitlab_team_members feature group으로 GitLab 팀 멤버에게도 활성화할 수 있습니다:

/chatops run feature set --feature-group=gitlab_team_members some_feature true

특정 그룹을 위해 기능 플래그를 활성화하려면 --group 플래그를 사용할 수 있습니다:

/chatops run feature set --group=gitlab-org some_feature true

--group은 사용자 네임스페이스와 함께 작동하지 않습니다. 일반적인 네임스페이스(그룹 포함)에 대해 기능 플래그를 활성화하려면 --namespace를 사용하세요:

/chatops run feature set --namespace=gitlab-org some_feature true
/chatops run feature set --namespace=myusername some_feature true

참여자 기반 게이트가 백분율보다 우선 적용됩니다. 예를 들어, group/project를 gitlab-org/gitlab로 고려하고 주어진 예제 기능을 some_feature라고 가정할 때, 다음 두 명령을 실행한다면:

/chatops run feature set --project=gitlab-org/gitlab some_feature true
/chatops run feature set some_feature 25 --actors

그럼 some_feature은 25%의 참여자와 항상 gitlab-org/gitlab과 상호 작용할 때 활성화됩니다. 이것은 기능 플래그 개발이 그룹 참여자를 사용하는 경우에 좋은 아이디어입니다.

Feature.enabled?(:some_feature, group)

여러 참여자를 쉼표로 구분하여 함께 전달할 수 있습니다:

/chatops run feature set --project=gitlab-org/gitlab,example-org/example-project some_feature true

/chatops run feature set --group=gitlab-org,example-org some_feature true

/chatops run feature set --namespace=gitlab-org,example-org some_feature true

마지막으로, 기능이 가능한 많은 경우에서 안정적으로 여겨지는지 확인하기 위해 기능 플래그를 전역적으로 활성화하여 완전히 롤아웃하는 것이 좋습니다. 다음을 실행하여 기능 플래그 상태를 항상 활성화로 변경합니다:

/chatops run feature set some_feature true

이렇게 하면 기능 플래그 상태가 기존 게이트(예: --group=gitlab-org)을 무시하고 항상 활성화됩니다.

참고: 사용자 기반 기능 게이트가 있으면, YAML 정의의 default_enabled 속성을 false에서 true로 전환해도 효과가 없습니다. 원하는 효과를 얻으려면 먼저 기능 게이트를 삭제해야 합니다.

예를 들어, ChatOps를 통해 기능 플래그가 설정됩니다:

/chatops run feature set --project=gitlab-org/gitlab some_feature true

YAML 정의의 default_enabled 속성이 true로 전환되어도, 원하는 효과를 얻기 위해 기능 게이트를 삭제해야 합니다:

/chatops run feature delete some_feature

액터의 백분율 대 시간 롤아웃의 백분율

특정 기능이 항상 사용자에 대해 켜거나 끄려면 액터의 백분율 롤아웃을 사용하세요. 이 경우에는 시간의 백분율 롤아웃을 피하세요.

Feature.enabled?이 코드에서 여러 번 사용되는 경우 시간의 백분율 롤아웃은 일관되지 않은 동작을 일으킬 수 있습니다. 왜냐하면 Feature.enabled?이 코드 경로에서 호출될 때마다 기능 플래그 값이 무작위로 변하기 때문입니다.

플래그 기능 비활성화

전역으로 활성화된 기능 플래그를 비활성화하려면 다음을 실행할 수 있습니다:

/chatops run feature set some_feature false

특정 프로젝트에 대해 활성화된 기능 플래그를 비활성화하려면 다음을 실행할 수 있습니다:

/chatops run feature set --project=gitlab-org/gitlab some_feature false

특정 프로젝트/그룹/사용자에 대해 기능 플래그를 선택적으로 비활성화할 수는 없으며, 기능 플래그를 구현 방법에 따라 선택적으로 비활성화할 수 있습니다.

만약 기능 플래그가 ChatOps를 통해 비활성화된 경우에는 YAML의 default_enabled 값보다 우선합니다. 다시 말해, 기능이 온프레미스 설치에는 활성화되어 있지만 GitLab.com에는 비활성화될 수 있습니다.

액터별 선택적 비활성화

기본적으로 액터별로 기능 플래그를 선택적으로 비활성화할 수는 없습니다.

# 이는 기대한 대로 작동하지 않습니다.
/chatops run feature set some_feature true
/chatops run feature set --project=gitlab-org/gitlab some_feature false

하지만, 두 개의 기능 플래그를 추가하면 조건문을 작성하여 동등한 선택적 비활성화가 가능합니다.

Feature.enabled?(:a_feature, project) && Feature.disabled?(:a_feature_override, project)

# 이는 gitlab-org/gitlab을 제외한 프로젝트 전역으로 기능 플래그를 활성화합니다.
/chatops run feature set a_feature true
/chatops run feature set --project=gitlab-org/gitlab a_feature_override true

액터 선택의 백분율 기반

여러 기능 플래그의 액터 백분율 롤아웃을 사용하는 경우 각 기능 플래그의 액터가 개별적으로 선택됩니다.

예를 들어, 특정 백분율의 액터에 대해 다음과 같은 기능 플래그가 활성화되어 있습니다:

/chatops run feature set feature-set-1 25 --actors
/chatops run feature set feature-set-2 25 --actors

프로젝트 A가 :feature-set-1를 활성화한 경우, 프로젝트 A에 :feature-set-2도 활성화될 것이 보장되지 않습니다.

자세한 내용은 플리퍼의 백분율 동작 원리을 참조하세요.

기능 플래그 활성화 후 메트릭 검증

기능 플래그를 활성화한 후에는 각 단계에서 관련 그래프를 모니터링해야 합니다:

dashboards.gitlab.net으로 이동합니다.
feature-flag를 활성화합니다.
변경 사항에 영향을 줄 수 있는 서비스 (예: sidekiq service, api service, 또는 web service)에 대해 Latency: Apdex를 확인합니다. 그런 다음 Service Overview Dashboards를 선택하고 변경과 관련된 대시보드를 선택합니다.

이 그림에서 기능 플래그가 09:46에서 활성화된 후 Apdex 점수가 감소하기 시작했고, 기능 플래그가 10:31에 비활성화되면서 서비스가 원래 값으로 돌아옴을 볼 수 있습니다:

기능 플래그 변경 로깅

ChatOps 레벨

GitLab.com(운영)에 영향을 주는 모든 기능 플래그 변경은 ChatOps를 통해 자동으로 이슈에 로그됩니다.

이 이슈는 gl-infra/feature-flag-log 프로젝트에서 만들어지며, 최소한 기능 플래그를 활성화하는 사람의 Slack 핸들, 시간 및 변경된 플래그 이름을 로깅합니다.

또한 해당 이슈는 GitLab 내부 Grafana 대시보드에 변경 사항을 보다 더 명확히 표시하기 위한 주석 마커로 게시됩니다.

이슈 형식의 변경 사항은 ChatOps 프로젝트에 제출할 수 있습니다.

인스턴스 레벨

어떠한 GitLab 인스턴스에도 영향을 주는 모든 기능 플래그 변경은 자동으로 features_json.log에 로그됩니다. Kibana를 통해 변경 이력을 검색할 수 있습니다. 또한 GitLab.com에 대한 기능 플래그 변경 이력은 Kibana에서 확인할 수 있습니다.

정리

기능 플래그는 더 이상 필요하지 않은 경우 즉시 제거되어야 합니다. 코드베이스에 추가로 있는 각 기능 플래그는 애플리케이션의 복잡성을 증가시키고 모든 가능한 조합을 커버하는 테스트 스위트에 대한 신뢰를 감소시킵니다. 또한 몇몇 환경에서 덮어쓰인 기능 플래그는 정의되지 않고 테스트되지 않은 시스템 동작을 유발할 수 있습니다.

development 타입의 기능 플래그는 지속적인 변경 사항을 롤아웃하기 위한 목적이므로 수명 주기가 짧아야 합니다. 2개의 마일스톤 이상 된 development 기능 플래그는 엔지니어링 매니저에게 보고됩니다. 보고 도구는 매월 실행됩니다. 예를 들어, 2021년 12월 보고서를 참조하세요.

development 기능 플래그가 코드베이스에 6개월 이상 남아 있는 경우 다음 중 하나의 조치를 취해야 합니다:

기능 플래그를 기본적으로 활성화하고 제거합니다.
인스턴스, 그룹 또는 프로젝트 설정으로 변환합니다.
아직 비활성화되어 있고 더 이상 필요하지 않은 경우 변경 사항을 되돌립니다.

기능 플래그를 제거하려면 하나의 머지 리퀘스트를 열어서 변경을 수행하세요. 머지 리퀘스트에서:

변경 사항 제거를 인지할 수 있도록 ~"feature flag" 라벨을 추가하세요.
머지 리퀘스트가 현재 버전으로 백포트되어야 하는 경우 패치 릴리스 런북 프로세스를 따르세요. 자세한 내용은 기능 플래그 프로세스를 참조하세요.
테스트를 포함하여 코드베이스에서 기능 플래그에 대한 모든 참조를 제거하세요.
저장소에서 기능에 대한 YAML 정의를 제거하세요.

위의 머지 리퀘스트가 병합된 후에는 다음을 수행해야 합니다:

/chatops run feature delete some_feature로 모든 환경에서 기능 플래그를 정리하세요.
코드베이스에서 기능 플래그가 제거된 후, 롤아웃 이슈를 닫으세요.

Cleanup ChatOps

기능 게이트가 코드베이스에서 제거된 경우, 해당 플래그가 배포된 데이터베이스에는 여전히 기능 레코드가 존재합니다. 해당 레코드는 MR이 모든 환경에 배포된 후에 삭제할 수 있습니다:

/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production

ChatOps를 사용하여 기능 플래그를 활성화하고 비활성화하십시오

변경 사항 롤아웃

사전 프로덕션 테스트를 위한 기능 활성화

시간 비율로 기능 플래그 활성화

GitLab.com에서 기능 활성화

변경 내용 통보

롤아웃 중 선택할 백분율 지침

A. 하루에 몇 번 실행되는 작업을 위한 기능 플래그

B. 하루에 수백 번 또는 수천 번 실행되는 작업을 위한 기능 플래그

C. 앱의 핵심에서 실행되는 작업을 위한 기능 플래그

D. 기능 플래그 출시의 알려지지 않은 영향

프로세스

액터의 백분율 대 시간 롤아웃의 백분율

플래그 기능 비활성화

액터별 선택적 비활성화

액터 선택의 백분율 기반

기능 플래그 활성화 후 메트릭 검증

기능 플래그 변경 로깅

ChatOps 레벨

인스턴스 레벨

정리

Cleanup ChatOps

도움말

기능 사용 가능성과 제품 평가판

도움받기