• 변경 사항 전개
  • 사전 프로덕션 테스트를 위한 기능 활성화
    • 시간의 백분율로 피처 플래그 활성화
  • GitLab.com의 기능 활성화
    • 변경 사항 통보
    • 전개하는 동안 선택할 백분율에 대한 지침
      • A. 하루에 몇 번 실행되는 작업을 위한 피처 플래그
      • B. 하루에 수백 또는 수천 회 실행되는 작업을 위한 피처 플래그
      • C. 앱의 핵심 부분에서 실행되는 작업에 대한 피처 플래그
      • D. 피처 플래그 릴리스의 알 수 없는 영향
    • 프로세스
      • 배우 및 시간 롤아웃의 배우 백분율 대 시간 롤아웃의 백분율
      • 피처 플래그 비활성화
    • 배우 별 선택적 비활성화
    • 백분율 기반 배우 선택
  • 피처 플래그 활성화 후 메트릭 확인
  • 피처 플래그 변경 로깅
    • ChatOps 수준
    • 인스턴스 수준
• 정리
  • 정리 ChatOps

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

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

액세스 권한을 요청하려면 ChatOps 문서에 따르세요.

프로젝트에 추가되면 액세스가 전파되었는지 테스트하세요. 다음을 실행합니다.

/chatops run feature --help

변경 사항 전개

환경에 변경 사항이 배포되면 사용자에게 기능을 전파하는 시간입니다. 변경 전파의 구체적인 절차는 변경에 따라 다를 수 있으므로 정확한 절차는 명확하지 않습니다. 그러나 일반적으로 변경을 점진적으로 전파하는 것을 권장하며, 모두에게 즉시 기능을 활성화하는 대신 점진적으로 변경하도록 권장합니다. 코드가 배포되기 전에 기능을 활성화하지 않도록 권장합니다. 이렇게 하면 기능 전파를 배포와 분리하여 각각의 영향을 메트릭하기 쉬워집니다.

GitLab 기능 라이브러리(Flipper 사용)는 시간의 백분율에 대한 변경을 지원합니다. 이는 GitLab ChatOps를 사용하여 제어할 수 있습니다.

현재까지 피처 플래그 명령어를 확인하려면 소스 코드를 참조하세요. 해당 파일의 모든 예제는 반드시 /chatops run 앞에 있어야 합니다.

오류가 발생하면 “앗! 이 작업을 수행할 수 없습니다. 이 사건은 보고됩니다.”라는 메시지가 표시되면 귀하의 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에서 명령을 실행하는 것이 강력히 권장됩니다.

시간의 백분율로 피처 플래그 활성화

시간의 백분율 피처 플래그는 배우날 수 있는 사람들의 백분율을 선호하므로 시간의 백분율 피처 플래그는 폐기되었습니다. 시간의 백분율 피처 플래그를 사용하는 것의 결과를 이해한다면 --ignore-random-deprecation-check를 사용하여 강제로 이를 실행할 수 있습니다.

GitLab.com의 기능 활성화

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

기능이 폐기되었다면 플래그를 활성화하지 마십시오.

변경 사항 통보

GitLab.com의 일부 피처 플래그 변경 사항은 회사 부분에게 통보되어야 합니다. 해당 개발자는 이것이 필요한지와 적절한 커뮤니케이션 수준을 결정해야 합니다. 이는 기능 및 영향을 고려하여 결정됩니다.

지침:

• 미리 #support_gitlab-com에 통보할 것을 고려하세요. 사용자 경험에 부작용이 있는 경우 기능을 줄이고 비활성화할 수 있도록 준비할 수 있습니다.
• 변경 관리 이슈를 생성할 수 있는 요건을 만족하는 경우, 중요도 지침에 따라 변경 관리 이슈를 생성하세요.
• 간단하고, 저위험, 쉽게 되돌릴 수 있는 피처 플래그에 대해 진행하여 프로덕션 환경에서 기능을 활성화하세요.
• 특정 그룹 또는 프로젝트에 대한 피처 플래그를 전환하는 지원 요청의 경우, 지원 업무 흐름에 개요된 절차를 따르세요.

전개하는 동안 선택할 백분율에 대한 지침

피처 플래그 전파 중에 선택할 백분율은 다양한 요소에 따라 달라집니다. 예를 들어:

• 피처 플래그가 자주 확인되어 가져다닐 정보를 충분히 수집하여 전파를 계속할 수 있을까요?
• 기능에 문제가 발생하면 얼마나 많은 요청 또는 고객이 영향을 받을 것인가?
• 기능에 문제가 발생하는 경우 다른 GitLab에서 사용 가능한 기능에 어떤 영향이 있을까요?
• 피처 플래그를 전파함으로써 가능한 성능 저하가 있을까요?

다양한 유형의 피처 플래그를 위해 전파를 고려하는 방법에 대한 몇 가지 예를 살펴보겠습니다.

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

하루에 몇 번 실행되는 작업에 새 기능을 릴리스한다고 가정해 보겠습니다. 예를 들어, 매지 업스트림 코너 잡을 위한 데이터베이스 쿼리 다시 작성와 같이 매일 또는 매 시간을 기준으로 실행되는 새 기능이 도입됩니다. 이러한 새로운 기능은 도입된 피처 플래그로 제어됩니다. 이 경우, 25% 또는 50%의 백분율로 전파하는 것이 적절한 선택일 것입니다. 그러나 작업에 문제가 발생하면 재시도될 것입니다. 따라서 제한된 백분율로 전파하는 것이 방법일 것입니다.

그러나 반드시 작업의 로그 결과를 로거에 기록해야 합니다. 최상의 로깅에 대한 지침을 참조하세요.

B. 하루에 수백 또는 수천 회 실행되는 작업을 위한 피처 플래그

귀하의 새롭게 도입된 기능 또는 변경 사항은 Sidekiq 작업에서 실행되는 것보다 더 고객에게 노출될 수 있습니다. 그러나 자주 실행되지 않을 수 있습니다. 이 경우, 결과를 수집하여 전파를 계속할지 여부를 결정하기 위해 충분한 백분율을 선택하세요. 이 경우에는 5% 또는 10%로 시작하고 로그를 모니터링하여 오류 또는 사용자에게 반환된 500 상태를 확인하세요.

전파를 계속하면서 백분율을 늘리다 보면 기능의 성능 영향을 고려해야 합니다. 여기서 Grafana의 지연 시간: Apdex 및 오류 비율 대시보드를 모니터링할 수 있습니다.

C. 앱의 핵심 부분에서 실행되는 작업에 대한 피처 플래그

가끔 GitLab 애플리케이션의 모든 측면에 영향을 미칠 수 있는 새로운 변경이 발생할 수 있습니다. 예를 들어 User, Project 또는 Namespace 같은 핵심 모델 중 하나의 데이터베이스 조회를 변경하는 경우입니다. 이러한 경우, 변경 요청을 통해 요청의 1% 이상 또는 그보다 더 적은 부분에 대해 기능을 릴리스하는 것이 사건을 피하기 위해 강력히 권장됩니다. 이 변경 요청 예를 참조하여 변경의 높은 영향력으로 약 0.1%의 요청에 대해 릴리스된 피처 플래그를 확인하세요.

랄아밍익깅 슨로주이:

1. 피처 플래그의 전체 롤아웃에 영향을 미칠 수 있는 1분당 요청의 예상 수를 추정합니다. 이는 데이터베이스 조회를 추적하여 달성할 수 있습니다. 여기의 지침을 참조하세요.
2. 롤아웃이 예상대로 되지 않는 경우에 영향을 받을 수 있는 합리적인 수의 요청 또는 사용자 수를 계산합니다.
3. (1)과 (2)에서 수집된 수치를 기반으로, 피처 플래그의 롤아웃을 시작할 합리적인 백분율을 계산합니다. 다음은 해당 계산의 예시입니다.
4. 피처 플래그의 롤아웃 이슈에 대한 결과를 의사소통할 수 있도록 해야 합니다.

D. 피처 플래그 릴리스의 알 수 없는 영향

어떤 백분율을 사용해야 할지 확신이 없는 경우, 안전하게 권장되는 옵션을 선택하고 다음 백분율을 선택하세요:

1. 1%
2. 10%
3. 25%
4. 50%
5. 75%
6. 100%

각 단계 사이에서는 잠시 기다리고 적절한 그래프를 모니터링해야 합니다. 정확한 대기 시간은 다를 수 있습니다. 어떤 기능은 몇 분이면 충분하고, 다른 기능은 몇 시간 또는 몇 일을 기다리는 것이 좋을 수 있습니다. 이는 전적으로 당신에 달려 있으며, 잠재적인 문제가 예상된다면 팀과 프로덕션 팀에 명확히 의사소통해야 합니다.

프로세스

피처 플래그 롤아웃을 활성화할 때, 시스템은 자동으로 "severity::1" 또는 ~"severity::2" 사건 또는 진행 중인 변경 이슈가 있는 경우 ChatOps 명령을 차단합니다. 예시:

/chatops run feature set gitaly_lfs_pointers_pipeline true

- 프로덕션 확인 실패!
- 활성 사건
  
  2021-06-29 Canary deployment failing QA tests

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

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

기능을 활성화하기 시작할 때, 첫 번째 /chatops 명령의 Slack 스레드에 관련된 피처 플래그 롤아웃 이슈에 링크를 제공하여 필요한 경우 사람들이 변경 사항을 이해할 수 있도록하세요.

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

/chatops run feature set new_navigation_bar 25 --random

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

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 기능 그룹을 사용하여 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)를 무시하고 피처 플래그 상태가 항상 활성화로 변경됩니다.

참고: 액터 기반 기능 게이트가 적용된 경우, 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도 활성화되어 있는 것은 보장할 수 없습니다.

자세한 내용은 여기에서 백분율이 Flipper에서 작동하는 방법을 확인하세요.

피처 플래그 활성화 후 메트릭 확인

피처 플래그를 켜면, 각 단계에서 관련 그래프를 모니터링해야 합니다:

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

위 그림에서 피처 플래그를 09:46에 활성화했을 때 Apdex 점수가 감소하기 시작한 것을 볼 수 있습니다. 그런 다음 피처 플래그가 10:31에 비활성화되고 서비스가 원래 값으로 돌아왔습니다:

피처 플래그 변경 로깅

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월 보고서를 참조하세요.

6개월 이후에도 development 피처 플래그가 코드베이스에 남아있는 경우 다음 작업 중 하나를 수행해야 합니다:

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

피처 플래그를 제거하려면 하나의 Merge Request를 엽니다. 이 MR에서:

1. 추가됩니다. ~"feature flag" 라벨은 제거를 알리도록 합니다.
2. MR이 현재 버전으로 백포팅되어야 하는 경우, 패치 릴리스 런북 프로세스를 따릅니다. 최종 릴리스에 기능이 포함되는 방법에 대한 자세한 내용은 피처 플래그 프로세스를 참조하세요.
3. 테스트를 포함하여 코드베이스에서 피처 플래그에 대한 모든 참조를 제거합니다.
4. 리포지터리에서 기능에 대한 YAML 정의를 제거합니다.

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

1. 모든 환경에서 피처 플래그를 정리합니다 /chatops run feature delete some_feature.
2. 피처 플래그가 코드베이스에서 제거된 후 피처 플래그에 대한 롤아웃 이슈를 닫습니다.

정리 ChatOps

특성 플래그가 코드베이스에서 제거된 후에도, 해당 플래그가 배포된 데이터베이스에 여전히 기록이 남아 있습니다. MR이 모든 환경에 배포된 후 레코드를 삭제할 수 있습니다:

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