This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @rymai @DylanGriffith devops non_devops 2023-11-01

GitLab 개발 및 운영에서의 Feature Flags 사용

이 블루프린트는 개발용 특징 플래그 아키텍처 블루프린트를 기반으로 합니다.

요약

Feature Flag는 GitLab의 개발 및 운영에서 중요하지만 현재 상태에서는 프로덕션 문제를 일으킬 수 있으며 많은 매뉴얼 및 유지 관리 작업을 도입할 수 있습니다.

이 블루프린트의 목표는 프로세스를 더 안전하고 유지 가능하며 가벼우며 자동화되고 투명하게 만드는 것입니다.

동기

피처 플래그 사용 사례

피처 플래그는 다양한 목적으로 사용할 수 있습니다.

  • GitLab.com 배포의 위험 완화(대부분의 feature flags): 프로덕션 사고 발생 시에 프로덕션에서 빠르게 feature flag를 활성화/비활성화할 수 있습니다.
  • 진행 중인 기능: 일부 기능은 복잡하며 여러 MR을 통해 구현해야 합니다. 완전히 구현될 때까지는 누구에게도 표시되지 않아야 합니다. 이 경우 feature flag를 사용하면 모든 변경 사항을 본래 기능을 사용하지 않고 주 브랜치에 Merge할 수 있습니다.
  • 베타 기능: 현재 형태로 모든 설계된 사용 사례에 대해 기능을 충분히 확장할 수 있고 지원할 수 있다는 확신이 없을 수 있습니다(예시). 또한, MVC로 간주하기에 충분히 완성되지 않은 기능에 대한 시나리오도 있습니다. 해당 경우에 flag를 제공하면 엔지니어 및 고객이 새로운 기능을 성능이 충분히 향상될 때까지 비활성화할 수 있습니다.
  • 운영: 사이트 신뢰성 엔지니어 또는 지원 엔지니어는 자원을 많이 소비하는 기능을 비활성화하여 인스턴스를 더 안정적이고 이용 가능한 상태로 유지할 수 있습니다. 다른 예로는 SaaS 전용 기능이 있습니다.
  • 실험: GitLab.com에서 A/B 테스트.
  • Worker(특별한 ops feature flag): Sidekiq worker의 동작을 제어하는 데 사용되며 Sidekiq 작업을 지연시키는 경우가 있습니다.

우리는 feature flag를 더 잘 분류해야 합니다.

피처 플래그와 관련된 프로덕션 사고

피처 플래그는 GitLab.com에서 프로덕션 사고를 일으켰습니다 (1, 2, 3).

GitLab.com의 안정성을 위해 이를 방지해야 합니다.

피처 플래그s로 인한 기술적 부채

피처 플래그는 현재 GitLab 코드베이스에 591개가 있어 기술적 부채의 계속적인 원인이 되고 있습니다.

GitLab 코드베이스의 장기적인 유지 관리 및 품질을 위해 feature flag 수를 줄여야 합니다.

목표

이 블루프린트의 목표는 다음을 통해 feature flag 프로세스를 개선하는 것입니다.

  • 더 안전하게
  • 더 유지 가능하게
  • 더 가벼우며 자동화되게
  • 더 투명하게

도전과제

복잡한 feature flag 롤아웃 프로세스

현재 feature flag 롤아웃 프로세스는 다음과 같습니다.

  • 복잡함: 롤아웃 문제가 매우 매뉴얼적이며 많은 체크박스가 포함됩니다(관련 없는 체크박스 포함). 엔지니어는 이러한 문제를 종종 사용하지 않으며 시간이 지날수록 잊혀지고 잊혀진다는 경향이 있습니다.
  • 매우 투명하지 않음: feature flag 변경 사항은 롤아웃 문제와 상당히 멀리 기록되어 있어 최신 feature flag 상태를 이해하기 어렵게 만듭니다.
  • 프로덕션 프로세스에서 멀리 떨어져 있음: 롤아웃 문제는 gitlab-org/gitlab 프로젝트에 생성됩니다(프로덕션 이슈 추적기와 거리가 멉니다).
  • feature flag를 롤아웃하기 위한 일관된 경로가 없음: 속도와 안전 사이의 트레이드 오프를 엔지니어의 판단에 맡겨둡니다. 롤아웃 단계의 표준화된 집합이 있어야 합니다.

기술적 부채와 코드베이스 복잡성

개발용 Feature Flags Architecture 블루프린트의 도전과제는 여전히 진행 중입니다.

또한 새로운 도전 과제가 있습니다.

  • feature flag가 기본적으로 활성화되어 있고 온프레미스 설치에서 비활성화 될 경우, feature flag가 제거되면 해당 기능이 갑자기 온프레미스 인스턴스에서 활성화되어 이전 동작으로 복귀할 수 없습니다.

feature flag 기본 상태 및 가시성에 대한 다중 진실원

현재 feature flag 기본 상태를 다른 대상을 위해 여러 곳에 표시합니다.

GitLab 고객

  • 사용자 설명서: GitLab 고객이 인스턴스에서 feature flag를 조정할 수 있도록 모든 feature flag 및 메타데이터를 나열합니다. 피처 플래그의 기본 상태를 확인하고 싶은 GitLab.com 사용자에게도 유용합니다.

사이트 안정성 및 배달 엔지니어

GitLab 엔지니어 및 인프라/품질 이사 / 이사, CTO

  • 내부 Sisense 대시보드: 시간에 따른 feature flag 메트릭 및 DevOps 그룹 단위로 그룹화된 내용을 제공합니다.

GitLab 엔지니어 및 제품 매니저

feature flag 기본 상태를 확인하고 싶은 누구든지

거의 모든 feature flag 이해관계자(개발 엔지니어, 엔지니어 매니저, 사이트 안정성, 배달 엔지니어)에 혼란을 야기시킵니다.

제안

피처 플래그 구현 및 사용 개선

새로운 피처 플래그 ‘타입’ 도입

development 피처 플래그 유형에는 실제로 여러 가지 사용 사례가 포함되어 있음이 명확합니다.

  • GitLab.com 배포 위험 완화. YAML 값: gitlab_com_derisk.
  • 진행 중인 기능. YAML 값: wip. 기능이 완료되면 beta로 유형을 변경할 수 있습니다. 기능의 확장성에 대한 몇 가지 의문이 여전히 있는 경우에만.
  • 베타 기능. YAML 값: beta.
note
  • 이러한 새로운 유형은 더 이상 사용해서는 안 되는 범용 development 유형을 대체합니다.
  • 뒷호환성은 더 이상 코드베이스에 development 피처 플래그가 없을 때까지 유지될 것입니다.

피처 플래그 유형별으로 제약 조건 도입

각 피처 플래그 유형에는 다음과 같은 특정 제약 조건이 할당될 것입니다.

  • default_enabled 속성에 대한 허용된 값
  • 최대 수명 (MLS): 피처 플래그가 도입될 때부터 (즉, master에 Merge될 때) 시작되는 기간. 전역 GitLab.com 활성화(또는 적용 가능한 경우 default_enabled: true)를 기준으로 시작되는 수명을 도입하지 않으므로, 가능한 한 빨리 피처 플래그를 롤아웃하고 삭제할 수 있도록 하기 위함입니다.

MLS는 해당 섹션 수준의 자동화, 보고 및 정기적인 검토 회의를 통해 강제될 것입니다.

다음은 각 피처 플래그 유형에 대한 제약 조건입니다:

  • gitlab_com_derisk
    • default_enabled를 true로 설정해서는 안 됨. 이러한 유형의 피처 플래그는 GitLab.com의 위험을 낮추기 위한 것이므로, 한 번 GitLab.com에서 활성화된 후에는 더 이상 코드베이스에 플래그를 유지할 필요가 없습니다. 이 유형의 피처 플래그로 인해 default_enabled: true는 어떠한 효과도 없을 것입니다.
    • 최대 수명: 2개월.
    • 추가 참고: 이러한 유형의 피처 플래그는 짧은 수명을 가지며 배포 관련되어 있기 때문에 GitLab의 모든 피처 플래그 페이지에 기록되지 않을 것입니다.
  • wip
    • default_enabled를 true로 설정해서는 안 됨. 필요한 경우, 이 유형은 기능이 완료된 후 beta로 변경할 수 있습니다.
    • 최대 수명: 4개월.
  • beta
    • default_enabled를 true로 설정할 수 있어서 기능을 베타로 모든 사용자에게 “배포”하고 확장 가능성 문제로 인해 비활성화할 수 있도록 합니다 (이상적으로는 특정 온프레미스 설치에서인 이유로만 비활성화해야 합니다).
    • 최대 수명: 6개월.
  • ops
    • default_enabled를 true로 설정할 수 있음.
    • 최대 수명: 무제한.
    • 추가 참고: 이 유형을 사용하는 것은 인스턴스 설정을 도입하지 않기로 신중하게 결정했음을 기억하세요.
  • experiment
    • default_enabled를 true로 설정해서는 안 됨.
    • 최대 수명: 6개월.

새로운 feature_issue_url 필드 도입

원래 기능 이슈의 URL을 유지하여 롤아웃 및 로깅 이슈와의 자동화된 상호 연결을 허용할 것입니다. 이 정보에 대한 새로운 필드는 feature_issue_url입니다.

예를 들어: 

---
name: auto_devops_banner_disabled
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/12345
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/678910
rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/9876
milestone: '16.5'
type: gitlab_com_derisk
group: group::pipeline execution

---
name: ai_mr_creation
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/12345
introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14218
rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/83652
milestone: '16.3'
type: beta
group: group::code review
default_enabled: true

피처 플래그 롤아웃 프로세스 효율화

  1. (프로세스) Production issue tracker에서 롤아웃 이슈 생성으로 전환하고, Change management issue template에 가까운 템플릿으로 조정합니다 (영감을 얻기 위해 이 이슈 참조). 따라서 롤아웃 이슈는 실제 프로덕션 변경 사항(예: 프로덕션에서 플래그의 활성화/비활성화)에 관련된 사항만 다루며, 프로덕션 변경 사항이 예상대로 작동하는 것이 확인되면 가능한 빨리 종료될 것입니다.
  2. (자동화) 대부분의 롤아웃 단계를 자동화하십시오.
  3. (문서/프로세스) 피처 플래그를 활성화한 후에도 (이상적으로는 그들의 일의 시작 시점에 플래그를 활성화해야 할 것입니다) 롤아웃 DRI(Directly Responsible Individual)을 몇 시간 동안 온라인 상태로 유지할 수 있도록 보장하십시오.
  4. (프로세스) 표준화된 일련의 롤아웃 단계를 제공하십시오. 고려해야 할 교환관계 사항은 다음과 같습니다.
    • 오류 발생 가능성
    • 영향 받는 총 활동 주체(사용자/요청/프로젝트/그룹). 예를 들어 1% 롤아웃 시 10만 명의 사용자가 로그인할 수 없는 상황은 나쁘다.
    • 각 단계 사이의 대기 시간. 일부 피처 플래그는 단계별로 10분만 기다리면 되지만, 일부 피처 플래그는 24시간을 기다려야 합니다. 각 단계에 불리한 영향이 없는지 자동으로 확인할 수 있는 자동화가 이상적입니다.

GitLab.com의 피처 플래그 기본 상태 및 현재 상태 및 상태 변경의 더 나은 SSOT 제공

GitLab 고객

사이트 신뢰성 및 배송 엔지니어

우리는 GitLab.com의 피처 플래그 상태 변경 로깅 전략의 유용성을 평가했으며, 내부 GitLab.com 피처 플래그 상태 변경 이슈 및 내부 GitLab.com 피처 플래그 상태 변경 로그가 서로 다른 사용자들에게 유용하다는 것으로 나타났습니다.

GitLab 엔지니어링 및 인프라/품질 이사 및 부사장, 그리고 CTO

GitLab 엔지니어링 및 제품 매니저

반복

이 작업은 피처 플래그 내부 사용의 개선의 일부로서 수행되고 있습니다. 이 epic은 이러한 변경 사항의 메타 이유를 설명합니다.

자원