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

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

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. 트래픽을 가지며 일부 개발 및 기타 관련 작업에 사용되는 프로덕션 CE 환경입니다. staging.gitlab.com은 GitLab.com 데이터베이스 및 리포지터리의 작은 하위 집합을 가지고 있으며 정규 트래픽이 없습니다. Staging은 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

GitLab.com에 대한 기능 활성화

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

기능이 폐기되었음, 피처 플래그를 활성화하지 마십시오.

변경 사항 통지

GitLab.com의 일부 피처 플래그 변경에 대해 회사의 일부에게 통지해야 합니다. 책임 있는 개발자는 이것이 필요한지 및 적절한 통지 수준을 결정해야 합니다. 이는 기능 및 그것이 가질 수 있는 영향의 종류에 따라 다릅니다.

지침:

• #support_gitlab-com에 미리 알릴 것을 고려하십시오. 사용자 경험에 어떤 영향을 미칠지 여부에 따라 해당 기능에 대한 부작용을 완화하고 피처 플래그를 비활성화할 수 있습니다.
• 변경 관리 이슈를 생성할 요구 사항을 충족하는 경우 중요도 지침에 따라 Change Management 이슈를 생성하십시오.
• 단순하고 저위험 그리고 쉽게 되돌릴 수 있는 기능에 대해 직접 프로덕션에 활성화하여 계속 진행하십시오.
• 특정 그룹이나 프로젝트의 피처 플래그를 전환하는 지원 요청의 경우, 지원 업무에 개요된 프로세스를 따르십시오.

전파 중에 선택할 시간의 백분율에 대한 지침

피처 플래그를 전파하는 동안 선택할 백분율을 선택하는 것은 여러 요소에 달려있습니다. 예를 들어 다음과 같은 요소에 따라 선택할 수 있습니다:

• 피처 플래그가 자주 확인되어 전파를 계속할 지 여부를 결정하려면 충분한 정보를 수집할 수 있나요?
• 기능에 문제가 발생하면 몇 개의 요청 또는 고객이 영향을 받을 것인가요?
• 기능에 문제가 발생하면 다른 GitLab 공개 기능에 영향을 미칠 수 있는 요소가 있나요?
• 피처 플래그를 전파하는 것에서 잠재적인 성능 저하가 있을 수 있나요?

다양한 유형의 피처 플래그에 대한 몇 가지 예를 들어 보고 각 경우에 피처 플래그 전파를 어떻게 고려할 수 있는지 살펴보겠습니다:

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

예를 들어, 일일 또는 시간별 크론 작업에서 몇 번 실행되는 새 기능을 출시하고자한다고 합시다. 그리고 이 새 기능은 새롭게 추가된 피처 플래그로 제어됩니다. 예를 들어, 데이터베이스 쿼리를 재작성하는 크론 작업. 이 경우 25% 또는 50%의 백분율로 전파하는 것이 수락할 수 있는 선택입니다.

그러나 작업자의 로그에 피처 플래그 확인 결과를 기록해야 합니다. 러브 등록 및 grape 요청에 대한 여기에서 로깅에 대한 가장 좋은 실천 방법을 확인하세요.

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

새롭게 도입된 기능 또는 변경 사항이 Sidekiq 작업에서 실행되는 것보다 고객에게 더 노출될 수 있습니다. 그러나 실행 빈도가 낮을 수 있습니다. 이 경우, 결과를 수집하기에 충분한 높은 백분율을 선택하여 계속 진행할지 여부를 알아내기 위해 시작할 수 있습니다. 이 경우에는 오류를 모니터링하거나 사용자에게 반환된 500 상태를 위해 로그를 확인하여, 예를 들어 5% 또는 10%로 시작할 수 있습니다.

그러나 롤아웃을 계속하면서 백분율을 늘릴 때는 해당 기능의 성능 영향을 고려해야 합니다. Latency: Apdex and error ratios 대시보드에서 Grafana를 통해 성능 영향을 모니터링할 수 있습니다.

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

가끔은 GitLab 애플리케이션의 모든 측면에 영향을 미칠 수 있는 새로운 변경 사항이 있을 수 있습니다. 예를 들어, User, Project 또는 Namespace와 같은 핵심 모델 중 하나의 데이터베이스 쿼리를 변경하는 경우입니다. 이 경우, 요청의 1%에 대해 기능을 배포하는 것이나 (변경 요청을 통해) 그보다 더 적은 비율로 기능을 배포하는 것이 잠재적 사고를 방지하기 위해 매우 권장됩니다. 변경 요청 예시를 확인하세요. 해당 변경 사항의 피처 플래그가 약 0.1%의 요청에 대해 출시된 예시입니다.

고객에게 큰 영향을 미치는 일이 없도록 롤아웃이 실행되는 과정을 확인하기 위해 다음 단계를 고려해보세요:

1. 100%의 피처 플래그 롤아웃으로 영향을 받을 수 있는 분당 요청 수를 추정합니다. 이를 데이터베이스 쿼리를 추적하여 알 수 있습니다. 여기에 있는 지침을 확인하세요.
2. 예상치 못한 상황이 발생했을 때 영향을 받을 수 있는 합리적인 요청 또는 사용자 수를 계산합니다.
3. (1)과 (2)에서 수집한 숫자를 기반으로 피처 플래그의 롤아웃에 시작할 합리적인 백분율을 계산합니다. 여기에 있는 예시를 참고하세요.
4. 피처 플래그의 롤아웃 문제에 대한 조사 결과를 팀과 제공팀에 명확히 전달해야 합니다.

D. 피처 플래그 출시의 알 수 없는 영향

어떤 백분율을 사용해야 하는지 확실하지 않은 경우, 안전하게 권장되는 옵션을 선택하고 다음과 같은 백분율을 선택합니다:

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

모든 단계 사이에서 약간의 시간을 기다려야 하며 적절한 그래프를 https://dashboards.gitlab.net에서 모니터링해야 합니다. 기다려야 하는 정확한 시간은 다를 수 있습니다. 어떤 기능은 몇 분이면 충분할 수도 있고, 다른 기능은 몇 시간이나 며칠이 경과해야 할 수도 있습니다. 모두 당신에게 달렸으며, 잠재적인 문제가 예상된다면 팀과 제공팀에 명확히 전달해야 합니다.

프로세스

피처 플래그 롤아웃을 활성화할 때 시스템은 활성화된 "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를 위반하지 않는지 확인하고 피처 플래그s and the Change Management Process를 준수하는지 확인하세요.

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

기능을 활성화하기 시작할 때, 해당 피처 플래그 롤아웃 문제에 대한 Slack 스레드에 관련 링크를 첫 번째 /chatops 명령의 스레드로 달아, 필요하다면 사람들이 변경을 이해할 수 있도록 할 수 있습니다.

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

/chatops run feature set new_navigation_bar 25 --random

(이하 생략됨)

배우 멜영업인 대비 롤아웃 비율 대비 시간의 백분율

특정 기능을 사용자에게 항상 켜거나 끌 수 있도록 하려면 배우의 백분율 롤아웃을 사용하십시오. 이 경우 시간의 백분율 롤아웃은 피하세요.

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를 확인합니다(예: 사이드킥 서비스, API 서비스 또는 웹 서비스). 그런 다음 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월용 리포트를 참조하십시오.

development 특성 플래그가 6개월이 지난 후에도 코드베이스에 남아있는 경우 다음 조치 중 하나를 취해야 합니다:

• 기본적으로 특성 플래그를 활성화하고 제거합니다.
• 인스턴스, 그룹 또는 프로젝트 설정으로 변환합니다.
• 아직 비활성화된 채로 필요하지 않다면 변경사항을 되돌립니다.

특성 플래그를 제거하려면 단 하나의 Merge Request를 열어 변경사항을 만들어야 합니다. MR에서:

1. ~"특성 플래그" 레이블을 추가하여 릴리스 매니저가 제거에 대해 인식하도록 합니다.
2. MR이 현재 버전으로 백포트되어야 하는 경우 패치 릴리스 실행북 프로세스를 따릅니다. 자세한 내용은 특성 플래그 프로세스를 참조하십시오.
3. 테스트를 포함하여 코드베이스의 특성 플래그에 대한 모든 참조를 제거합니다.
4. 리포지터리의 특성에 대한 YAML 정의를 제거합니다.

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

1. 모든 환경에서 특성 플래그를 정리하십시오. /chatops run feature delete some_feature로 실행합니다.
2. 특성 플래그를 코드베이스에서 제거한 후 해당 특성 플래그의 롤아웃 이슈를 닫습니다.

ChatOps 정리

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

/chatops run feature delete <기능-플래그-이름> --dev --pre --staging --staging-ref --production