InfoGrab DocsInfoGrab Docs

ChatOps를 사용하여 기능 플래그 활성화 및 비활성화

요약

이 문서는 GitLab 제품 개발에 기여하는 방법을 설명합니다. 스테이징 및 프로덕션과 같이 GitLab이 제공하는 환경에서 기능 플래그 뒤의 기능을 켜거나 끄려면 ChatOps 봇에 대한 접근 권한이 필요합니다. ChatOps 문서를 따라 접근 권한을 요청하세요.

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

스테이징 및 프로덕션과 같이 GitLab이 제공하는 환경에서 기능 플래그 뒤의 기능을 켜거나 끄려면 ChatOps 봇에 대한 접근 권한이 필요합니다. ChatOps 봇은 현재 ops 인스턴스에서 실행 중이며, 이는 GitLab.com 또는 dev.gitlab.org와는 다른 인스턴스입니다.

ChatOps 문서를 따라 접근 권한을 요청하세요.

프로젝트에 추가된 후 접근 권한이 전파되었는지 확인하려면 다음을 실행하세요:

/chatops gitlab run feature --help

변경 사항 롤아웃#

변경 사항이 환경에 배포되면 사용자에게 기능을 롤아웃할 시간입니다. 롤아웃의 정확한 절차는 변경 사항마다 다를 수 있으므로 지정되어 있지 않습니다. 그러나 일반적으로 모든 사용자에게 즉시 활성화하는 대신 점진적으로 변경 사항을 롤아웃하는 것을 권장합니다. 또한 코드가 배포되기 전에 기능을 활성화하지 않도록 권장합니다. 이렇게 하면 기능 롤아웃과 배포를 분리하여 각각의 영향을 별도로 측정하기 더 쉬워집니다.

GitLab 기능 라이브러리(Flipper 사용, 기능 플래그 프로세스 가이드에서 다룸)는 사용자의 특정 비율만큼 변경 사항을 롤아웃하는 것을 지원합니다. 이는 GitLab ChatOps를 통해 제어할 수 있습니다.

최신 기능 플래그 명령어 목록은 소스 코드를 참조하세요. 해당 파일의 모든 예시 앞에는 /chatops gitlab 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, 또는 #chat-ops-test 채널에서 명령어를 실행하도록 강력히 권장합니다.

특정 비율의 액터에 대해 기능 플래그 활성화#

임의의 액터에 대해 25% 확률로 기능을 활성화하려면 Slack에서 다음을 실행하세요:

/chatops gitlab run feature set new_navigation_bar 25 --actors --dev
/chatops gitlab run feature set new_navigation_bar 25 --actors --staging

롤아웃을 무작위로 적용할 액터 선택에 대해서는 액터 비율을 참조하세요.

GitLab.com에 대한 기능 활성화#

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

기능이 더 이상 사용되지 않는 경우, 플래그를 활성화하지 마세요.

변경 사항 공지#

GitLab.com의 일부 기능 플래그 변경 사항은 회사 내 일부 부서에 공지해야 합니다. 담당 개발자는 이것이 필요한지, 그리고 적절한 공지 수준을 결정해야 합니다. 이는 기능과 그 영향의 종류에 따라 다릅니다.

가이드라인:

  • 사전에 #support_gitlab-com에 알리세요. 기능이 사용자 경험에 부작용이 있을 경우, 영향을 완화하고 기능 플래그를 비활성화할 수 있습니다.

기능 플래그가 무엇을 하는지 간략한 설명을 포함하세요. GitLab Duo Agentic Chat에 다음과 같이 요청하는 것부터 시작할 수 있습니다: Explain the feature flag <feature-flag-name> in the gitlab-org/gitlab project

롤아웃 중 선택할 비율 가이드라인#

기능 플래그 롤아웃 중 비율 선택은 다양한 요소에 따라 다릅니다. 예를 들면:

  • 기능 플래그가 충분히 자주 확인되어 롤아웃을 계속 진행해도 안전한지 결정할 충분한 정보를 수집할 수 있나요?

  • 기능에 문제가 발생하면 얼마나 많은 요청 또는 고객이 영향을 받나요?

  • 문제가 발생하면 롤아웃으로 인해 영향을 받는 다른 공개 GitLab 기능이 있나요?

  • 기능 플래그 롤아웃으로 인한 성능 저하 가능성이 있나요?

다양한 유형의 기능 플래그에 대한 몇 가지 예시와 이러한 경우 롤아웃을 어떻게 고려할 수 있는지 살펴보겠습니다:

A. 하루에 몇 번만 실행되는 작업의 기능 플래그#

예를 들어, 하루에 몇 번만 cron job에서 실행되는 새 기능을 릴리즈하는 경우, 이 기능이 새로 도입된 기능 플래그로 제어됩니다. 예를 들어, cron job의 데이터베이스 쿼리 재작성. 이 경우, 25% 미만의 비율로 기능 플래그를 릴리즈하면 롤아웃 진행 여부에 대한 피드백이 느릴 수 있습니다. 또한, cron job이 실패하면 재시도합니다. 따라서 문제가 발생해도 그 결과가 크지 않습니다. 이 경우 25% 또는 50% 비율로 릴리즈하는 것이 적절한 선택입니다.

하지만 워커의 로그에 기능 플래그 확인 결과를 기록해야 합니다. 로깅 모범 사례에 대한 자세한 내용은 로깅 컨텍스트 메타데이터(Rails 또는 Grape 요청을 통해)를 참조하세요.

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

새로 도입한 기능이나 변경 사항이 Sidekiq job에서 실행되는 것보다 고객에게 더 직접적으로 노출될 수 있습니다. 하지만 자주 실행되지 않을 수 있습니다. 이 경우, 진행 여부를 알기 위해 결과를 수집할 만큼 높은 비율을 선택하세요. 이 경우 5% 또는 10%에서 시작하는 것을 고려하면서 오류나 사용자에게 반환된 500 상태를 로그에서 모니터링하세요.

롤아웃을 계속하고 비율을 높임에 따라 기능의 성능 영향을 살펴봐야 합니다. Grafana에서 지연 시간: Apdex 및 오류율 대시보드를 모니터링하는 것을 고려하세요.

C. 앱의 핵심 부분에서 실행되는 작업의 기능 플래그#

때로는 GitLab 애플리케이션의 모든 측면에 영향을 미칠 수 있는 새로운 변경 사항이 있습니다. 예를 들어, User, Project 또는 Namespace와 같은 핵심 모델 중 하나에서 데이터베이스 쿼리를 변경하는 경우. 이 경우, 어떤 인시던트도 피하기 위해 요청의 1% 또는 그보다 적은 비율(변경 요청을 통해)로 기능을 릴리즈하는 것이 강력히 권장됩니다. 변경의 높은 영향 때문에 약 0.1%의 요청에 릴리즈된 기능 플래그의 변경 요청 예시를 참조하세요.

롤아웃이 많은 고객에게 영향을 미치지 않도록 다음 단계를 따르는 것을 고려하세요:

  • 기능 플래그 롤아웃의 100%로 인해 영향을 받을 수 있는 분당 요청 수를 추정하세요. 이는 데이터베이스 쿼리를 추적하여 달성할 수 있습니다. 여기의 지침을 참조하세요.

  • 롤아웃이 예상대로 진행되지 않을 경우 영향을 받을 수 있는 합리적인 요청 또는 사용자 수를 계산하세요.

  • (1)과 (2)에서 수집한 숫자를 기반으로 기능 플래그 롤아웃을 시작할 합리적인 비율을 계산하세요. 이러한 계산의 예시가 있습니다.

  • 기능 플래그의 롤아웃 이슈에 조사 결과를 공유하세요.

D. 기능 플래그 릴리즈의 알 수 없는 영향#

어떤 비율을 사용할지 확실하지 않다면, 안전한 권장 옵션을 선택하고 다음 비율을 사용하세요:

  • 1%

  • 10%

  • 25%

  • 50%

  • 75%

  • 100%

각 단계 사이에 잠시 기다리면서 https://dashboards.gitlab.net에서 적절한 그래프를 모니터링해야 합니다. 기다려야 하는 정확한 시간은 다를 수 있습니다. 일부 기능은 몇 분으로 충분하지만, 다른 기능은 몇 시간 또는 심지어 며칠을 기다려야 할 수 있습니다. 이는 전적으로 여러분에게 달려 있으며, 잠재적인 문제를 예상하는 경우 팀과 프로덕션 팀에 명확하게 전달하세요.

프로세스#

기능 플래그 롤아웃을 활성화할 때, 활성화된 "severity::1" 또는 ~"severity::2" 인시던트나 진행 중인 변경 이슈가 있으면 시스템이 자동으로 ChatOps 명령이 성공하지 못하도록 차단합니다. 예를 들면:

/chatops gitlab run feature set gitaly_lfs_pointers_pipeline true

- Production checks fail!
- active incidents

  2021-06-29 Canary deployment failing QA tests

기능 플래그를 활성화하기 전에 프로덕션 변경 잠금 기간을 위반하지 않고 기능 플래그 및 변경 관리 프로세스를 준수하는지 확인하세요.

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

액터 비율 롤아웃#

사용자, 프로젝트, 그룹 또는 현재 요청이나 job과 같은 액터의 25%에 대해 기능을 활성화하려면 Slack에서 다음을 실행하세요:

/chatops gitlab run feature set some_feature 25 --actors

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

feature_flag_state = Zlib.crc32("some_feature:#{actor.id}") % (100 * 1_000) < 25 * 1_000
# where : is a `User`, `Group`, `Project` and actor is an instance

개발 중에는 기능의 특성에 따라 액터 선택을 해야 합니다.

사용자 중심 기능의 경우:

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 gitlab run feature set --project=gitlab-org/gitlab some_feature true

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

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

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

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

--group 플래그를 사용하여 특정 그룹에 대해 기능 플래그를 활성화할 수 있습니다:

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

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

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

액터 기반 게이트는 비율보다 먼저 적용됩니다. 예를 들어, group/project가 gitlab-org/gitlab이고 주어진 예시 기능이 some_feature일 때, 다음 2가지 명령어를 실행하면:

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

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

Feature.enabled?(:some_feature, group)

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

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

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

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

마지막으로, 기능이 가능한 많은 경우에서 안정적으로 간주되는지 확인하기 위해 다음을 실행하여 전역적으로 플래그를 활성화하는 방식으로 기능을 완전히 롤아웃해야 합니다:

/chatops gitlab run feature set some_feature true

이렇게 하면 기능 플래그 상태가 항상 활성화로 변경되어 위 프로세스의 기존 게이트 (예: --group=gitlab-org)를 재정의합니다.

참고로, 액터 기반 기능 게이트가 있는 경우, YAML 정의의 default_enabled 속성을 false에서 true로 전환해도 아무런 효과가 없습니다. 먼저 기능 게이트를 삭제해야 합니다.

예를 들어, 기능 플래그가 ChatOps를 통해 설정된 경우:

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

YAML 정의의 default_enabled 속성이 true로 전환될 때, 원하는 효과를 내려면 기능 게이트를 삭제해야 합니다:

/chatops gitlab run feature delete some_feature
시간 비율 롤아웃 (더 이상 사용되지 않음)#

이전에는 25% 확률로 기능을 활성화하기 위해 Slack에서 다음을 실행했습니다:

/chatops gitlab run feature set new_navigation_bar 25 --random

이 명령어는 GitLab.com에 대해 new_navigation_bar 기능을 활성화합니다. 그러나 이 명령어는 전체 사용자의 25%에 대해 기능을 활성화하지 않습니다. 대신, enabled?로 기능을 확인할 때 25% 확률로 true를 반환합니다.

시간 비율 기능 플래그는 이제 Feature.current_request 액터를 사용하는 액터 비율을 위해 더 이상 사용되지 않습니다. 액터를 사용하지 않는 것의 문제점은 무작위 선택이 요청이나 job 실행당 한 번이 아니라 Feature.enabled?를 호출할 때마다 평가된다는 것입니다. 이는 상태가 왔다갔다 하는 문제로 이어질 수 있습니다. 예를 들면:

feature_flag_state = rand < (25 / 100.0)

현재로서는 시간 비율 기능 플래그의 사용을 계속 허용합니다. 롤아웃 중에는 ChatOps의 --ignore-random-deprecation-check 스위치를 사용하여 강제로 적용할 수 있습니다.

기능 플래그 비활성화#

전역적으로 활성화된 기능 플래그를 비활성화하려면 다음을 실행하세요:

/chatops gitlab run feature set some_feature false

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

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

기능 플래그 구현의 특정 방법을 적용하지 않으면 특정 프로젝트/그룹/사용자에 대해 기능 플래그를 선택적으로 비활성화할 수 없습니다.

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

액터별 선택적 비활성화#

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

# This will not work how you would expect.
/chatops gitlab run feature set some_feature true
/chatops gitlab run feature set --project=gitlab-org/gitlab some_feature false

그러나 두 개의 기능 플래그를 추가하면 동등한 선택적 비활성화가 가능하도록 조건문을 작성할 수 있습니다.

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

# This will enable a feature flag globally, except for gitlab-org/gitlab
/chatops gitlab run feature set a_feature true
/chatops gitlab run feature set --project=gitlab-org/gitlab a_feature_override true

비율 기반 액터 선택#

여러 기능 플래그에서 액터의 비율 롤아웃을 사용할 때, 각 기능 플래그의 액터는 별도로 선택됩니다.

예를 들어, 다음 기능 플래그가 특정 비율의 액터에 대해 활성화됩니다:

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

프로젝트 A에 :feature-set-1이 활성화되어 있다고 해서 프로젝트 A에 :feature-set-2도 활성화되어 있다는 보장이 없습니다.

자세한 내용은 Flipper에서 비율이 작동하는 방식을 참조하세요.

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

기능 플래그를 켠 후 각 단계 사이에 관련 그래프를 모니터링해야 합니다:

  • dashboards.gitlab.net으로 이동하세요.

  • feature-flag를 켜세요.

  • 변경 사항의 영향을 받을 수 있는 서비스(sidekiq service, api service 또는 web service 등)에 대한 Latency: Apdex를 모니터링하세요. 그런 다음 Service Overview Dashboards를 선택하고 변경 사항과 관련이 있을 수 있는 대시보드를 선택하여 더 심층적인 대시보드를 확인하세요.

이 그림에서 09:46에 기능 플래그가 활성화된 후 Apdex 점수가 하락하기 시작했음을 알 수 있습니다. 기능 플래그는 10:31에 비활성화되었고, 서비스는 원래 값으로 돌아갔습니다:

[

](/19.1/development/feature_flags/img/feature-flag-metrics_v15_8.png)

일부 기능은 특히 위험도가 높고 비즈니스에 중요한 기능의 경우 며칠에 걸친 광범위한 모니터링이 필요합니다. 반면 다른 기능은 롤아웃을 계속하기 전에 24시간 모니터링만 필요할 수 있습니다.

롤아웃을 시작하기 전에 필요한 모니터링의 범위를 결정하는 것이 권장됩니다.

기능 플래그 변경 로깅#

ChatOps 수준#

ChatOps를 통해 GitLab.com(프로덕션)에 영향을 미치는 모든 기능 플래그 변경 사항은 자동으로 이슈에 기록됩니다.

이슈는 gl-infra/feature-flag-log 프로젝트에 생성되며, 최소한 기능 플래그를 활성화한 사람의 Slack 핸들, 시간, 변경된 플래그의 이름이 기록됩니다.

이슈는 변경 사항을 더욱 가시적으로 만들기 위해 GitLab 내부 Grafana 대시보드에 주석 마커로도 게시됩니다.

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

인스턴스 수준#

모든 GitLab 인스턴스에 영향을 미치는 모든 기능 플래그 변경 사항은 자동으로 features_json.log에 기록됩니다. Kibana에서 변경 히스토리를 검색할 수 있습니다. 또한 GitLab.com의 기능 플래그 변경 히스토리에 Kibana에서 접근할 수 있습니다.

정리#

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

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

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

  • 기본적으로 기능 플래그를 활성화하고 제거하세요.

  • 인스턴스, 그룹 또는 프로젝트 설정으로 변환하세요.

  • 여전히 비활성화되어 더 이상 필요하지 않은 경우 변경 사항을 되돌리세요.

제로 다운타임 업그레이드 호환성#

기능 플래그를 제거하기 전에, 보호하는 코드가 GitLab Self-Managed 인스턴스의 제로 다운타임 업그레이드 중 혼합 버전 노드에서 안전하게 실행될 수 있는지 고려하세요.

제로 다운타임 업그레이드 중에는 다양한 컴포넌트(Rails, Sidekiq 등)가 코드의 다른 버전을 동시에 실행합니다. 기능 플래그가 쓰기 경로, 캐시 키 또는 컴포넌트 간에 공유된 상태 전환을 제어하는 경우, 구 버전 컴포넌트는 새 버전 컴포넌트에서 플래그가 제거되었을 때도 여전히 올바르게 동작해야 합니다. 실제 예시는 인시던트 #562149를 참조하세요.

기능 플래그는 호환성 경계가 아닙니다. 플래그를 제거하거나(또는 default_enabled: true로 설정하는 것)는 해당 코드가 혼합 버전 노드에서 안전하게 실행될 수 있게 만들지 않습니다. 롤링 업그레이드 중에는 이전 버전의 컴포넌트가 플래그가 비활성화된 상태로 계속 실행됩니다.

올바른 접근 방식은 확장-수축 패턴입니다. 기능 플래그에 특정한 가이드는 해당 문서의 기능 플래그 섹션도 참조하세요.

데이터 쓰기, 캐시 키 또는 상태 전환을 제어하는 플래그의 경우, 세 개의 마일스톤에 걸쳐 패턴을 적용하세요:

  • 마일스톤 N (확장): 기존 동작을 유지하면서 새로운 동작을 도입하세요. 보호된 코드가 혼합 버전 노드에서 안전하게 실행되도록 만드세요. 예를 들어, 플래그가 Redis 캐시 쓰기를 제어하는 경우, 구 버전 컴포넌트의 정리 경로가 플래그가 활성화된 것에 의존하지 않도록 하세요. 기존 코드 경로와 새 코드 경로 모두 안전하게 공존해야 합니다.

  • 마일스톤 N+1 (마이그레이션): 모든 소비자가 새 코드 경로를 사용하도록 업데이트하세요. 확장 단계가 완료되고 어떤 컴포넌트도 기존 경로에 의존하지 않는지 확인하세요.

  • 마일스톤 N+2 (수축): 플래그와 기존 코드 경로에 대한 모든 참조를 제거하세요.

데이터 쓰기, 캐시 키 또는 상태 전환을 제어하지 않는 플래그(예: 순수 UI 또는 동작 토글)의 경우, 이 다중 마일스톤 패턴이 필수는 아니지만 여전히 모범 사례로 권장됩니다.

기능 플래그를 제거하려면 변경 사항을 적용할 하나의 머지 리퀘스트를 여세요. MR에서:

  • 릴리즈 관리자가 제거를 인식할 수 있도록 ~"feature flag" 라벨을 추가하세요.

  • 머지 리퀘스트를 현재 버전으로 백포트해야 하는 경우, 패치 릴리즈 런북 프로세스를 따르세요. 자세한 내용은 기능 플래그 프로세스를 참조하세요.

  • 테스트를 포함하여 코드베이스에서 기능 플래그에 대한 모든 참조를 제거하세요.

  • 리포지터리에서 기능에 대한 YAML 정의를 제거하세요.

위의 MR이 머지된 후 다음을 수행해야 합니다:

  • /chatops gitlab run feature delete some_feature를 사용하여 모든 환경에서 기능 플래그를 정리하세요.

  • 기능 플래그가 코드베이스에서 제거된 후 기능 플래그의 롤아웃 이슈를 닫으세요.

정리 ChatOps#

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

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

기능 플래그 상태 확인#

다음 ChatOps 명령어를 사용하여 기능 플래그의 현재 상태를 확인할 수 있습니다:

/chatops gitlab run feature get <feature-flag-name>

이것은 읽기 전용 명령어이므로 다음 방법으로 프로덕션 채널이 지저분해지는 것을 피할 수 있습니다:

  • #chat-ops-test Slack 채널에서 실행하기

  • ChatOps 봇에게 직접 메시지로 보내기

이 명령어의 결과는 다음을 표시합니다:

  • 기능 플래그 존재 여부

  • 현재 상태(활성화/비활성화)

  • 구성된 비율 롤아웃 또는 액터 기반 게이트

ChatOps를 사용하여 기능 플래그 활성화 및 비활성화

GitLab v19.1
원문 보기
요약

이 문서는 GitLab 제품 개발에 기여하는 방법을 설명합니다. 스테이징 및 프로덕션과 같이 GitLab이 제공하는 환경에서 기능 플래그 뒤의 기능을 켜거나 끄려면 ChatOps 봇에 대한 접근 권한이 필요합니다. ChatOps 문서를 따라 접근 권한을 요청하세요.

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

스테이징 및 프로덕션과 같이 GitLab이 제공하는 환경에서 기능 플래그 뒤의 기능을 켜거나 끄려면 ChatOps 봇에 대한 접근 권한이 필요합니다. ChatOps 봇은 현재 ops 인스턴스에서 실행 중이며, 이는 GitLab.com 또는 dev.gitlab.org와는 다른 인스턴스입니다.

ChatOps 문서를 따라 접근 권한을 요청하세요.

프로젝트에 추가된 후 접근 권한이 전파되었는지 확인하려면 다음을 실행하세요:

/chatops gitlab run feature --help

변경 사항 롤아웃#

변경 사항이 환경에 배포되면 사용자에게 기능을 롤아웃할 시간입니다. 롤아웃의 정확한 절차는 변경 사항마다 다를 수 있으므로 지정되어 있지 않습니다. 그러나 일반적으로 모든 사용자에게 즉시 활성화하는 대신 점진적으로 변경 사항을 롤아웃하는 것을 권장합니다. 또한 코드가 배포되기 전에 기능을 활성화하지 않도록 권장합니다. 이렇게 하면 기능 롤아웃과 배포를 분리하여 각각의 영향을 별도로 측정하기 더 쉬워집니다.

GitLab 기능 라이브러리(Flipper 사용, 기능 플래그 프로세스 가이드에서 다룸)는 사용자의 특정 비율만큼 변경 사항을 롤아웃하는 것을 지원합니다. 이는 GitLab ChatOps를 통해 제어할 수 있습니다.

최신 기능 플래그 명령어 목록은 소스 코드를 참조하세요. 해당 파일의 모든 예시 앞에는 /chatops gitlab 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, 또는 #chat-ops-test 채널에서 명령어를 실행하도록 강력히 권장합니다.

특정 비율의 액터에 대해 기능 플래그 활성화#

임의의 액터에 대해 25% 확률로 기능을 활성화하려면 Slack에서 다음을 실행하세요:

/chatops gitlab run feature set new_navigation_bar 25 --actors --dev
/chatops gitlab run feature set new_navigation_bar 25 --actors --staging

롤아웃을 무작위로 적용할 액터 선택에 대해서는 액터 비율을 참조하세요.

GitLab.com에 대한 기능 활성화#

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

기능이 더 이상 사용되지 않는 경우, 플래그를 활성화하지 마세요.

변경 사항 공지#

GitLab.com의 일부 기능 플래그 변경 사항은 회사 내 일부 부서에 공지해야 합니다. 담당 개발자는 이것이 필요한지, 그리고 적절한 공지 수준을 결정해야 합니다. 이는 기능과 그 영향의 종류에 따라 다릅니다.

가이드라인:

  • 사전에 #support_gitlab-com에 알리세요. 기능이 사용자 경험에 부작용이 있을 경우, 영향을 완화하고 기능 플래그를 비활성화할 수 있습니다.

기능 플래그가 무엇을 하는지 간략한 설명을 포함하세요. GitLab Duo Agentic Chat에 다음과 같이 요청하는 것부터 시작할 수 있습니다: Explain the feature flag <feature-flag-name> in the gitlab-org/gitlab project

롤아웃 중 선택할 비율 가이드라인#

기능 플래그 롤아웃 중 비율 선택은 다양한 요소에 따라 다릅니다. 예를 들면:

  • 기능 플래그가 충분히 자주 확인되어 롤아웃을 계속 진행해도 안전한지 결정할 충분한 정보를 수집할 수 있나요?

  • 기능에 문제가 발생하면 얼마나 많은 요청 또는 고객이 영향을 받나요?

  • 문제가 발생하면 롤아웃으로 인해 영향을 받는 다른 공개 GitLab 기능이 있나요?

  • 기능 플래그 롤아웃으로 인한 성능 저하 가능성이 있나요?

다양한 유형의 기능 플래그에 대한 몇 가지 예시와 이러한 경우 롤아웃을 어떻게 고려할 수 있는지 살펴보겠습니다:

A. 하루에 몇 번만 실행되는 작업의 기능 플래그#

예를 들어, 하루에 몇 번만 cron job에서 실행되는 새 기능을 릴리즈하는 경우, 이 기능이 새로 도입된 기능 플래그로 제어됩니다. 예를 들어, cron job의 데이터베이스 쿼리 재작성. 이 경우, 25% 미만의 비율로 기능 플래그를 릴리즈하면 롤아웃 진행 여부에 대한 피드백이 느릴 수 있습니다. 또한, cron job이 실패하면 재시도합니다. 따라서 문제가 발생해도 그 결과가 크지 않습니다. 이 경우 25% 또는 50% 비율로 릴리즈하는 것이 적절한 선택입니다.

하지만 워커의 로그에 기능 플래그 확인 결과를 기록해야 합니다. 로깅 모범 사례에 대한 자세한 내용은 로깅 컨텍스트 메타데이터(Rails 또는 Grape 요청을 통해)를 참조하세요.

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

새로 도입한 기능이나 변경 사항이 Sidekiq job에서 실행되는 것보다 고객에게 더 직접적으로 노출될 수 있습니다. 하지만 자주 실행되지 않을 수 있습니다. 이 경우, 진행 여부를 알기 위해 결과를 수집할 만큼 높은 비율을 선택하세요. 이 경우 5% 또는 10%에서 시작하는 것을 고려하면서 오류나 사용자에게 반환된 500 상태를 로그에서 모니터링하세요.

롤아웃을 계속하고 비율을 높임에 따라 기능의 성능 영향을 살펴봐야 합니다. Grafana에서 지연 시간: Apdex 및 오류율 대시보드를 모니터링하는 것을 고려하세요.

C. 앱의 핵심 부분에서 실행되는 작업의 기능 플래그#

때로는 GitLab 애플리케이션의 모든 측면에 영향을 미칠 수 있는 새로운 변경 사항이 있습니다. 예를 들어, User, Project 또는 Namespace와 같은 핵심 모델 중 하나에서 데이터베이스 쿼리를 변경하는 경우. 이 경우, 어떤 인시던트도 피하기 위해 요청의 1% 또는 그보다 적은 비율(변경 요청을 통해)로 기능을 릴리즈하는 것이 강력히 권장됩니다. 변경의 높은 영향 때문에 약 0.1%의 요청에 릴리즈된 기능 플래그의 변경 요청 예시를 참조하세요.

롤아웃이 많은 고객에게 영향을 미치지 않도록 다음 단계를 따르는 것을 고려하세요:

  • 기능 플래그 롤아웃의 100%로 인해 영향을 받을 수 있는 분당 요청 수를 추정하세요. 이는 데이터베이스 쿼리를 추적하여 달성할 수 있습니다. 여기의 지침을 참조하세요.

  • 롤아웃이 예상대로 진행되지 않을 경우 영향을 받을 수 있는 합리적인 요청 또는 사용자 수를 계산하세요.

  • (1)과 (2)에서 수집한 숫자를 기반으로 기능 플래그 롤아웃을 시작할 합리적인 비율을 계산하세요. 이러한 계산의 예시가 있습니다.

  • 기능 플래그의 롤아웃 이슈에 조사 결과를 공유하세요.

D. 기능 플래그 릴리즈의 알 수 없는 영향#

어떤 비율을 사용할지 확실하지 않다면, 안전한 권장 옵션을 선택하고 다음 비율을 사용하세요:

  • 1%

  • 10%

  • 25%

  • 50%

  • 75%

  • 100%

각 단계 사이에 잠시 기다리면서 https://dashboards.gitlab.net에서 적절한 그래프를 모니터링해야 합니다. 기다려야 하는 정확한 시간은 다를 수 있습니다. 일부 기능은 몇 분으로 충분하지만, 다른 기능은 몇 시간 또는 심지어 며칠을 기다려야 할 수 있습니다. 이는 전적으로 여러분에게 달려 있으며, 잠재적인 문제를 예상하는 경우 팀과 프로덕션 팀에 명확하게 전달하세요.

프로세스#

기능 플래그 롤아웃을 활성화할 때, 활성화된 "severity::1" 또는 ~"severity::2" 인시던트나 진행 중인 변경 이슈가 있으면 시스템이 자동으로 ChatOps 명령이 성공하지 못하도록 차단합니다. 예를 들면:

/chatops gitlab run feature set gitaly_lfs_pointers_pipeline true

- Production checks fail!
- active incidents

  2021-06-29 Canary deployment failing QA tests

기능 플래그를 활성화하기 전에 프로덕션 변경 잠금 기간을 위반하지 않고 기능 플래그 및 변경 관리 프로세스를 준수하는지 확인하세요.

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

액터 비율 롤아웃#

사용자, 프로젝트, 그룹 또는 현재 요청이나 job과 같은 액터의 25%에 대해 기능을 활성화하려면 Slack에서 다음을 실행하세요:

/chatops gitlab run feature set some_feature 25 --actors

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

feature_flag_state = Zlib.crc32("some_feature:#{actor.id}") % (100 * 1_000) < 25 * 1_000
# where : is a `User`, `Group`, `Project` and actor is an instance

개발 중에는 기능의 특성에 따라 액터 선택을 해야 합니다.

사용자 중심 기능의 경우:

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 gitlab run feature set --project=gitlab-org/gitlab some_feature true

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

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

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

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

--group 플래그를 사용하여 특정 그룹에 대해 기능 플래그를 활성화할 수 있습니다:

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

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

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

액터 기반 게이트는 비율보다 먼저 적용됩니다. 예를 들어, group/project가 gitlab-org/gitlab이고 주어진 예시 기능이 some_feature일 때, 다음 2가지 명령어를 실행하면:

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

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

Feature.enabled?(:some_feature, group)

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

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

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

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

마지막으로, 기능이 가능한 많은 경우에서 안정적으로 간주되는지 확인하기 위해 다음을 실행하여 전역적으로 플래그를 활성화하는 방식으로 기능을 완전히 롤아웃해야 합니다:

/chatops gitlab run feature set some_feature true

이렇게 하면 기능 플래그 상태가 항상 활성화로 변경되어 위 프로세스의 기존 게이트 (예: --group=gitlab-org)를 재정의합니다.

참고로, 액터 기반 기능 게이트가 있는 경우, YAML 정의의 default_enabled 속성을 false에서 true로 전환해도 아무런 효과가 없습니다. 먼저 기능 게이트를 삭제해야 합니다.

예를 들어, 기능 플래그가 ChatOps를 통해 설정된 경우:

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

YAML 정의의 default_enabled 속성이 true로 전환될 때, 원하는 효과를 내려면 기능 게이트를 삭제해야 합니다:

/chatops gitlab run feature delete some_feature
시간 비율 롤아웃 (더 이상 사용되지 않음)#

이전에는 25% 확률로 기능을 활성화하기 위해 Slack에서 다음을 실행했습니다:

/chatops gitlab run feature set new_navigation_bar 25 --random

이 명령어는 GitLab.com에 대해 new_navigation_bar 기능을 활성화합니다. 그러나 이 명령어는 전체 사용자의 25%에 대해 기능을 활성화하지 않습니다. 대신, enabled?로 기능을 확인할 때 25% 확률로 true를 반환합니다.

시간 비율 기능 플래그는 이제 Feature.current_request 액터를 사용하는 액터 비율을 위해 더 이상 사용되지 않습니다. 액터를 사용하지 않는 것의 문제점은 무작위 선택이 요청이나 job 실행당 한 번이 아니라 Feature.enabled?를 호출할 때마다 평가된다는 것입니다. 이는 상태가 왔다갔다 하는 문제로 이어질 수 있습니다. 예를 들면:

feature_flag_state = rand < (25 / 100.0)

현재로서는 시간 비율 기능 플래그의 사용을 계속 허용합니다. 롤아웃 중에는 ChatOps의 --ignore-random-deprecation-check 스위치를 사용하여 강제로 적용할 수 있습니다.

기능 플래그 비활성화#

전역적으로 활성화된 기능 플래그를 비활성화하려면 다음을 실행하세요:

/chatops gitlab run feature set some_feature false

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

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

기능 플래그 구현의 특정 방법을 적용하지 않으면 특정 프로젝트/그룹/사용자에 대해 기능 플래그를 선택적으로 비활성화할 수 없습니다.

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

액터별 선택적 비활성화#

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

# This will not work how you would expect.
/chatops gitlab run feature set some_feature true
/chatops gitlab run feature set --project=gitlab-org/gitlab some_feature false

그러나 두 개의 기능 플래그를 추가하면 동등한 선택적 비활성화가 가능하도록 조건문을 작성할 수 있습니다.

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

# This will enable a feature flag globally, except for gitlab-org/gitlab
/chatops gitlab run feature set a_feature true
/chatops gitlab run feature set --project=gitlab-org/gitlab a_feature_override true

비율 기반 액터 선택#

여러 기능 플래그에서 액터의 비율 롤아웃을 사용할 때, 각 기능 플래그의 액터는 별도로 선택됩니다.

예를 들어, 다음 기능 플래그가 특정 비율의 액터에 대해 활성화됩니다:

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

프로젝트 A에 :feature-set-1이 활성화되어 있다고 해서 프로젝트 A에 :feature-set-2도 활성화되어 있다는 보장이 없습니다.

자세한 내용은 Flipper에서 비율이 작동하는 방식을 참조하세요.

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

기능 플래그를 켠 후 각 단계 사이에 관련 그래프를 모니터링해야 합니다:

  • dashboards.gitlab.net으로 이동하세요.

  • feature-flag를 켜세요.

  • 변경 사항의 영향을 받을 수 있는 서비스(sidekiq service, api service 또는 web service 등)에 대한 Latency: Apdex를 모니터링하세요. 그런 다음 Service Overview Dashboards를 선택하고 변경 사항과 관련이 있을 수 있는 대시보드를 선택하여 더 심층적인 대시보드를 확인하세요.

이 그림에서 09:46에 기능 플래그가 활성화된 후 Apdex 점수가 하락하기 시작했음을 알 수 있습니다. 기능 플래그는 10:31에 비활성화되었고, 서비스는 원래 값으로 돌아갔습니다:

[

](/19.1/development/feature_flags/img/feature-flag-metrics_v15_8.png)

일부 기능은 특히 위험도가 높고 비즈니스에 중요한 기능의 경우 며칠에 걸친 광범위한 모니터링이 필요합니다. 반면 다른 기능은 롤아웃을 계속하기 전에 24시간 모니터링만 필요할 수 있습니다.

롤아웃을 시작하기 전에 필요한 모니터링의 범위를 결정하는 것이 권장됩니다.

기능 플래그 변경 로깅#

ChatOps 수준#

ChatOps를 통해 GitLab.com(프로덕션)에 영향을 미치는 모든 기능 플래그 변경 사항은 자동으로 이슈에 기록됩니다.

이슈는 gl-infra/feature-flag-log 프로젝트에 생성되며, 최소한 기능 플래그를 활성화한 사람의 Slack 핸들, 시간, 변경된 플래그의 이름이 기록됩니다.

이슈는 변경 사항을 더욱 가시적으로 만들기 위해 GitLab 내부 Grafana 대시보드에 주석 마커로도 게시됩니다.

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

인스턴스 수준#

모든 GitLab 인스턴스에 영향을 미치는 모든 기능 플래그 변경 사항은 자동으로 features_json.log에 기록됩니다. Kibana에서 변경 히스토리를 검색할 수 있습니다. 또한 GitLab.com의 기능 플래그 변경 히스토리에 Kibana에서 접근할 수 있습니다.

정리#

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

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

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

  • 기본적으로 기능 플래그를 활성화하고 제거하세요.

  • 인스턴스, 그룹 또는 프로젝트 설정으로 변환하세요.

  • 여전히 비활성화되어 더 이상 필요하지 않은 경우 변경 사항을 되돌리세요.

제로 다운타임 업그레이드 호환성#

기능 플래그를 제거하기 전에, 보호하는 코드가 GitLab Self-Managed 인스턴스의 제로 다운타임 업그레이드 중 혼합 버전 노드에서 안전하게 실행될 수 있는지 고려하세요.

제로 다운타임 업그레이드 중에는 다양한 컴포넌트(Rails, Sidekiq 등)가 코드의 다른 버전을 동시에 실행합니다. 기능 플래그가 쓰기 경로, 캐시 키 또는 컴포넌트 간에 공유된 상태 전환을 제어하는 경우, 구 버전 컴포넌트는 새 버전 컴포넌트에서 플래그가 제거되었을 때도 여전히 올바르게 동작해야 합니다. 실제 예시는 인시던트 #562149를 참조하세요.

기능 플래그는 호환성 경계가 아닙니다. 플래그를 제거하거나(또는 default_enabled: true로 설정하는 것)는 해당 코드가 혼합 버전 노드에서 안전하게 실행될 수 있게 만들지 않습니다. 롤링 업그레이드 중에는 이전 버전의 컴포넌트가 플래그가 비활성화된 상태로 계속 실행됩니다.

올바른 접근 방식은 확장-수축 패턴입니다. 기능 플래그에 특정한 가이드는 해당 문서의 기능 플래그 섹션도 참조하세요.

데이터 쓰기, 캐시 키 또는 상태 전환을 제어하는 플래그의 경우, 세 개의 마일스톤에 걸쳐 패턴을 적용하세요:

  • 마일스톤 N (확장): 기존 동작을 유지하면서 새로운 동작을 도입하세요. 보호된 코드가 혼합 버전 노드에서 안전하게 실행되도록 만드세요. 예를 들어, 플래그가 Redis 캐시 쓰기를 제어하는 경우, 구 버전 컴포넌트의 정리 경로가 플래그가 활성화된 것에 의존하지 않도록 하세요. 기존 코드 경로와 새 코드 경로 모두 안전하게 공존해야 합니다.

  • 마일스톤 N+1 (마이그레이션): 모든 소비자가 새 코드 경로를 사용하도록 업데이트하세요. 확장 단계가 완료되고 어떤 컴포넌트도 기존 경로에 의존하지 않는지 확인하세요.

  • 마일스톤 N+2 (수축): 플래그와 기존 코드 경로에 대한 모든 참조를 제거하세요.

데이터 쓰기, 캐시 키 또는 상태 전환을 제어하지 않는 플래그(예: 순수 UI 또는 동작 토글)의 경우, 이 다중 마일스톤 패턴이 필수는 아니지만 여전히 모범 사례로 권장됩니다.

기능 플래그를 제거하려면 변경 사항을 적용할 하나의 머지 리퀘스트를 여세요. MR에서:

  • 릴리즈 관리자가 제거를 인식할 수 있도록 ~"feature flag" 라벨을 추가하세요.

  • 머지 리퀘스트를 현재 버전으로 백포트해야 하는 경우, 패치 릴리즈 런북 프로세스를 따르세요. 자세한 내용은 기능 플래그 프로세스를 참조하세요.

  • 테스트를 포함하여 코드베이스에서 기능 플래그에 대한 모든 참조를 제거하세요.

  • 리포지터리에서 기능에 대한 YAML 정의를 제거하세요.

위의 MR이 머지된 후 다음을 수행해야 합니다:

  • /chatops gitlab run feature delete some_feature를 사용하여 모든 환경에서 기능 플래그를 정리하세요.

  • 기능 플래그가 코드베이스에서 제거된 후 기능 플래그의 롤아웃 이슈를 닫으세요.

정리 ChatOps#

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

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

기능 플래그 상태 확인#

다음 ChatOps 명령어를 사용하여 기능 플래그의 현재 상태를 확인할 수 있습니다:

/chatops gitlab run feature get <feature-flag-name>

이것은 읽기 전용 명령어이므로 다음 방법으로 프로덕션 채널이 지저분해지는 것을 피할 수 있습니다:

  • #chat-ops-test Slack 채널에서 실행하기

  • ChatOps 봇에게 직접 메시지로 보내기

이 명령어의 결과는 다음을 표시합니다:

  • 기능 플래그 존재 여부

  • 현재 상태(활성화/비활성화)

  • 구성된 비율 롤아웃 또는 액터 기반 게이트