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 개발 및 운영에서의 피처 플래그 사용

이 청사진은 개발 피처 플래그 아키텍처 청사진을 기반으로 합니다.

요약

피처 플래그는 GitLab의 개발과 운영에서 모두 중요하지만, 현재의 프로세스 상태에서는 프로덕션 문제를 야기할 수 있으며, 많은 매뉴얼 및 유지 관리 작업을 도입할 수 있습니다.

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

동기

피처 플래그 사용 사례

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

  • GitLab.com 배포의 위험 완화 (대부분의 피처 플래그): 프로덕션에서 갑자기 피처 플래그를 활성화/비활성화할 수 있도록 합니다.
  • 진행 중인 기능: 일부 기능은 복잡하여 여러 MR을 통해 구현되어야 합니다. 완전히 구현될 때까지 아무도 볼 수 없어야 합니다. 이 경우 피처 플래그를 사용하여 실제로 기능을 사용하지 않으면서 모든 변경 사항을 기본 브랜치에 Merge할 수 있습니다.
  • 베타 기능: 현재 형태로 실제 설계된 모든 사용 사례에 대해 기능을 충분히 확장, 지원 및 유지할 수 있을지 확신하지 못할 수 있습니다(예시). 또한 MVC로 간주할만큼 기능이 충분히 완성되지 않은 경우도 있습니다. 이 경우에는 엔지니어 및 고객이 성능이 충분하지 않을 때까지 새 기능을 비활성화할 수 있도록 플래그를 제공합니다.
  • 운영: 사이트 신뢰성 엔지니어 또는 지원 엔지니어는 이러한 플래그를 사용하여 인스턴스를 더 안정적이고 사용 가능한 상태로 유지하기 위해 잠재적으로 자원 집중적인 기능을 비활성화할 수 있습니다. 또 다른 예는 SaaS 전용 기능입니다.
  • 실험: GitLab.com에서 A/B 테스트.
  • Worker (특별한 ops 피처 플래그): Sidekiq 작업을 연기하는 등의 Sidekiq 작업을 제어하는 데 사용됩니다.

우리는 피처 플래그를 더 잘 분류해야 합니다.

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

피처 플래그는 GitLab.com에서 프로덕션 사건을 야기했습니다(1, 2, 3).

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

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

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

GitLab 코드베이스의 장기적인 유지보수와 품질을 위해 피처 플래그 수를 줄여야 합니다.

목표

이 청사진의 목표는 다음과 같은 프로세스를 통해 피처 플래그를 개선하는 것입니다:

  • 더 안전하게 만들기
  • 더 유지 가능하게 만들기
  • 더 가볍고 자동화되도록 만들기
  • 더 투명하게 만들기

도전 과제

복잡한 피처 플래그 롤아웃 프로세스

피처 플래그 롤아웃 프로세스는 현재 다음과 같습니다.

  • 복잡함: 매뉴얼이 매우 많으며 불필요한 확인란이 많이 포함된 롤아웃 문제입니다. 엔지니어들은 종종 이러한 문제를 사용하지 않으며 시간이 지남에 따라 쇠화 및 잊혀집니다.
  • 매우 투명하지 않음: 피처 플래그 변경 사항이 롤아웃 문제에서 매우 먼 여러 곳에 기록되어 있어 최신 피처 플래그 상태를 이해하기 어렵게 만듭니다.
  • 프로덕션 프로세스에서 멀리 떨어짐: 롤아웃 문제는 gitlab-org/gitlab 프로젝트에서 만들어지며(프로덕션 이슈 트래커에서 상당히 멀리 떨어짐) 상태화된 롤아웃 단계의 표준화된 집합이 있어야 합니다.

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

개발 피처 플래그 아키텍처 청사진의 도전 과제는 여전히 유효합니다.

게다가 새로운 도전 과제들이 있습니다.

  • 기본적으로 활성화된 피처 플래그가 온프레미스 설치에서 비활성화되면, 피처 플래그가 제거되면 해당 기능이 온프레미스 인스턴스에서 갑자기 활성화되어 이전 동작으로 롤백할 수 없게 됩니다.

피처 플래그 기본 상태 및 가시성에 대한 여러 소스

우리는 피처 플래그의 기본 상태를 여러 군중을 위해 여러 곳에서 표시합니다.

GitLab 고객

  • 사용자 문서: GitLab 고객이 자체 인스턴스에서 피처 플래그를 조정할 수 있도록 모든 피처 플래그와 메타데이터를 나열합니다. 또한 피처 플래그의 기본 상태를 확인하려는 GitLab.com 사용자에게도 유용합니다.

사이트 신뢰성 및 제공 엔지니어

GitLab 엔지니어 및 인프라/품질 디렉터, 부사장 및 CTO

GitLab 엔지니어 및 제품 매니저

피처 플래그 기본 상태를 확인하려는 사람들

이로 인해 거의 모든 피처 플래그 이해권자(개발 엔지니어, 엔지니어 관리자, 사이트 신뢰성, 제공 엔지니어)들에게 혼란을 야기합니다.

제안

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

새로운 피처 플래그 유형 도입

개발 피처 플래그 유형은 실제로 여러 사용 사례를 포함한다는 것이 명백합니다.

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

피처 플래그 유형별 제약 조건 소개

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

  • default_enabled 속성에 대한 허용된 값
  • 최대 수명 (MLS): 피처 플래그가 소개된 시점부터 시작하는 지속 기간(즉, master에 Merge될 때).

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가 피처 플래그를 활성화한 후 몇 시간 동안 온라인 상태를 유지 (이상적으로는 하루를 시작할 때 피처 플래그를 활성화해야 함)하여 피처 플래그에 문제가 발생할 경우를 대비합니다.
  4. (프로세스) 표준화된 롤아웃 단계를 제공합니다. 고려해야 할 점은 다음과 같습니다:
    • 오류가 발생할 가능성
    • 피처 플래그 롤아웃에 영향을 받는 총 사용자 수/요청/프로젝트/그룹 등, 예: 1%에 대한 롤아웃 시 10만 명의 사용자가 로그인할 수 없는 것은 나쁜 일입니다
    • 각 단계 사이에 기다릴 시간. 일부 피처 플래그는 단계당 10분을 기다려야 하지만, 일부 플래그는 24시간을 기다려야 합니다. 이상적으로는 각 단계에 대해 부정적인 영향이 없는지 적극적으로 확인하는 자동화가 있어야 합니다.

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

GitLab 고객

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

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

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

GitLab 엔지니어 및 제품 관리자

반복

이 작업은 피처 플래그의 내부 사용 개선의 일환으로 진행됩니다. 이 Epic은 이러한 변경 사항을 위한 메타 이유를 설명합니다.

리소스