• 변경 사항 배포
  • 사전 프로덕션 테스트를 위한 기능 활성화
    • 시간의 일부분을 사용하여 기능 플래그 활성화
  • GitLab.com에서 기능 활성화
    • 변경 사항 통보
    • 전파 중에 선택할 백분율에 대한 가이드라인
      • A. 하루에 몇 번 실행되는 작업용 기능 플래그
      • B. 하루에 수백 번 또는 몇 천 번 실행되는 작업에 대한 기능 플래그
      • C. 앱의 핵심에서 실행되는 작업에 대한 기능 플래그
      • D. 기능 플래그 릴리스의 알 수 없는 영향
    • 프로세스
      • 백분율 시간 롤아웃
      • 배우 소수 요소 vs 시간 배포의 비율
      • 기능 플래그 비활성화
    • 배우 별 선택적 비활성화
    • 배우 기반 비율 선택
  • 기능 플래그를 활성화한 후 메트릭 확인
  • 기능 플래그 변경 기록
    • ChatOps 레벨
    • 인스턴스 레벨
• 정리
  • 챗옵스 정리

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

참고: 이 문서는 GitLab 제품 개발에 기여하는 방법에 대해 설명합니다. 만약 특성 플래그를 사용하여 애플리케이션에서 기능을 표시하거나 숨기고 싶다면, 대신 이 특성 플래그 정보를 확인하세요.

스테이징 및 프로덕션 등 GitLab에서 제공하는 환경에서 특성 플래그 뒤의 기능을 켜거나 끄려면 ChatOps 봇에 대한 액세스 권한이 필요합니다. ChatOps 봇은 현재 ops 인스턴스에서 실행되고 있으며, 이는 GitLab.com 또는 dev.gitlab.org와는 다릅니다.

프로젝트에 액세스를 요청하려면 ChatOps 문서를 따르세요.

프로젝트에 추가되었는지 확인하려면 접근 권한을 가져와서 다음을 실행하세요:

/chatops run feature --help

변경 사항 배포

환경에 변경 사항이 배포되면 사용자에게 기능을 전파하는 시간입니다. 변경 내용의 구체적인 절차는 변할 수 있기 때문에 정의되어 있지 않으며, 일반적으로 변경 사항을 점진적으로 전파하는 것이 좋습니다. 또한 코드가 배포되기 전에 기능을 활성화하는 것이 좋습니다. 이렇게 하면 기능 전파와 배포를 별도로 분리하여 둘의 영향을 별도로 측정하기 쉽습니다.

GitLab 기능 라이브러리는 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. 트래픽을 갖고 있으며 일부 개발 및 관련 작업에 사용됩니다. 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에 통보합니다. 그래서 기능이 사용자 경험에 영향을 미칠 경우, 해당 부분을 완화하고 기능 플래그를 비활성화할 수 있습니다.
• 변경 관리 이슈를 생성하기 위한 기준에 따라 변경 관리 이슈를 생성합니다.
• 간단하고, 낮은 위험, 쉽게 되돌릴 수 있는 기능에 대해서는 계속 생산 환경에서 기능을 활성화하세요.
• 특정 그룹 또는 프로젝트용으로 기능 플래그를 전환하는 지원 요청의 경우, 지원 워크플로우에 기술된 프로세스를 따릅니다.

전파 중에 선택할 백분율에 대한 가이드라인

기능 플래그 전파 중 어떤 백분율을 선택할지는 다양한 요인에 달려 있습니다. 예를 들어:

• 기능 플래그가 자주 확인되는가하여 전파를 계속 진행할지에 대한 충분한 정보를 수집할 수 있는가?
• 기능에 문제가 발생할 경우, 얼마나 많은 요청 또는 고객이 영향을 받을 것인가?
• 기능에 문제가 발생하면, 다른 GitLab 공개 기능이 전파에 영향을 받을 것인가?
• 기능 플래그를 전파하는 것으로 성능이 저하될 가능성이 있는가?

다양한 유형의 기능 플래그를 위한 선택 백분율에 대해 몇 가지 예시를 살펴보겠습니다.

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

하루에 몇 번 실행되는 새로운 기능을 배포하려면, 예를 들어 매일 또는 매시간 cron 작업에서 실행되는 새로운 기능을 제어하는 데이터베이스 쿼리를 다시 작성하는 경우를 가정해 보겠습니다. 이 경우 기능 플래그의 백분율이 25% 이하로 공개하면 전파 진행 여부에 대한 느린 피드백을 받을 수 있습니다. 또한, cron 작업이 실패하면 다시 시도할 것입니다. 따라서 어떤 문제가 발생해도 그 결과는 크지 않을 것입니다. 이 경우 25% 또는 50%의 백분율로 전파하는 것이 적절한 선택일 것입니다.

그러나 작업자의 로그에 기능 플래그 확인 결과를 로깅하는 것이 중요합니다. 로깅에 대한 가이드는 여기에서 확인할 수 있습니다.

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

새롭게 도입한 기능 또는 변경 사항이 Sidekiq 작업에서 실행되는 것보다 고객과 더 맞닿은 경우가 있습니다. 하지만 이는 자주 실행되지 않을 수 있습니다. 이 경우, 결과를 수집할 만큼의 높은 백분율을 선택하여 진행할지 여부를 파악하기 위해 5% 또는 10%를 고려할 수 있습니다. 이 과정에서 오류를 모니터링하거나 사용자에게 500 오류 상태가 반환되는지 로그를 모니터링할 수 있습니다.

그러나 롤아웃을 계속하고 백분율을 늘릴 때에는 기능의 성능 영향을 고려해야 합니다. 기능의 성능 영향을 고려할 수 있으며 Latency: Apdex 및 오류 비율 그라파나 대시보드를 모니터링할 수 있습니다.

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

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

롤아웃이 많은 고객에게 영향을 미치지 않도록 하려면 다음 단계를 따라야 합니다:

1. 전체 기능 플래그 롤아웃에 영향을 미칠 수 있는 분당 요청 수를 추정합니다. 이는 데이터베이스 쿼리를 추적하여 달성할 수 있습니다. 여기의 지침을 확인하세요.
2. 롤아웃이 예상대로 진행되지 않을 경우 영향을 받을 수 있는 합리적인 요청 또는 사용자 수를 계산합니다.
3. (1)과 (2)에서 수집한 데이터를 기반으로 기능 플래그를 롤아웃하기 위한 합리적인 시작 백분율을 계산합니다. 다음은 그러한 계산의 예시입니다.
4. 기능 플래그의 롤아웃 이슈에 대한 조사 결과를 팀과 Production 팀에 명확히 전달해야 합니다.

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

사용할 백분율을 확실하게 모른다면 안전하게 권장된 옵션을 선택하고 다음 백분율을 선택하세요:

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

각 단계 사이에서 적절한 그래프를 dashboards.gitlab.net에서 모니터링하고 잠시 기다리는 것이 좋습니다. 몇 분이면 충분한 경우도 있지만, 다른 경우에는 몇 시간 또는 심지어 며칠 동안 기다릴 수도 있습니다. 이 점은 전적으로 당신에게 달려있으며 잠재적 문제가 예상된다면 팀과 Production 팀에 명확하게 전달해야 합니다.

프로세스

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

/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를 위반하지 않고 기능 플래그 및 변경 관리 프로세스를 준수하는지 확인하세요.

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

백분율 시간 롤아웃

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

/chatops run feature set new_navigation_bar 25 --random

참고: 백분율 시간 기능 플래그는 백분율 기반 액터에 비해 사용이 지원되지 않습니다. 백분율 시간 기능 플래그를 사용하는 결과에 대한 이해가 있다면 --ignore-random-deprecation-check를 사용하여 강제로 실행할 수 있습니다.

이는 다음 공식을 기반으로 기능 플래그를 true로 설정합니다:

feature_flag_state = rand < (25 / 100.0)

이는 new_navigation_bar가 기능의 이름이고 GitLab.com을 위해 기능을 활성화하는 것이며, 이 때 전체 사용자의 25%에 대해 항상 true를 반환할 것이라는 것입니다.

배우 소수 요소 vs 시간 배포의 비율

특정 기능을 사용자에 대해 항상 켜거나 끄려면 소수 요소 비율 배포를 사용하십시오. 이 경우 시간의 비율 배포를 사용하지 마십시오.

시간의 비율 배포는 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. 변경으로 영향을 받을 수 있는 서비스의 Latency: Apdex를 확인합니다 (예: sidekiq 서비스, api 서비스, web 서비스). 그런 다음 Service Overview Dashboards를 선택하고 변경과 관련된 대시보드를 선택합니다.

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

특정 기능은 비즈니스 운영에 매우 중요하고 위험이 높은 경우 여러 일 동안 철저하게 확인해야 할 수 있습니다. 반면에, 다른 기능은 전개를 계속하기 전 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개월 이상 된 경우 다음 중 하나의 조치를 취해야 합니다.

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

기능 플래그를 제거하려면 위의 MR 중 하나를 엽니다.

1. 릴리스 매니저가 구조화된 이력을 인식할 수 있도록 ~"feature flag" 라벨을 추가합니다.
2. MR이 현재 버전으로 백포트되어야 하는 경우 패치 릴리스 런북 프로세스를 따릅니다. 자세한 내용은 기능 플래그 프로세스를 참조하세요.
3. 코드베이스에서 기능 플래그에 대한 모든 참조를 포함하여 테스트를 모두 제거합니다.
4. 저장소에서 기능에 대한 YAML 정의를 제거합니다.

위의 MR이 병합된 후 다음을 수행해야 합니다.

1. /chatops run feature delete some_feature를 사용하여 모든 환경에서 기능 플래그를 정리합니다.
2. 기능 플래그를 코드베이스에서 제거한 후 기능 플래그의 전개 이슈를 닫습니다.

챗옵스 정리

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

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