GitLab 개발에서의 피처 플래그

GitLab 제품 개발 및 운영에서 피처 플래그를 사용하는 방법과 유형, 정의, 테스트 방법을 설명합니다.

이 페이지는 개발자가 피처 플래그를 통해 GitLab 제품의 개발과 운영에 기여하는 방법을 설명합니다. 자체 애플리케이션에서 기능을 표시하거나 숨기는 커스텀 피처 플래그를 생성하려면 피처 플래그 생성 을 참고합니다. GitLab의 피처 플래그 전체 목록 도 제공됩니다. Warning 새로 도입되는 피처 플래그는 모두 기본적으로 비활성화 되어야 하며 액터와 함께 사용 해야 합니다. 설계 문서: (최신) GitLab 개발 및 운영에서의 피처 플래그 사용 개발 피처 플래그 아키텍처 이 문서는 피처 플래그의 내부 사용 개선 에픽의 일환으로 계속 작업 중입니다. 제안 사항은 새 이슈로 등록해 해당 에픽에 연결합니다. 피처 플래그 라이프사이클 개요 를 확인하거나 피처 플래그 사용 여부 판단 에 도움이 필요하면 피처 플래그 라이프사이클 핸드북 페이지를 참고합니다. 피처 플래그를 사용해야 하는 경우 # 핸드북의 "피처 플래그를 사용해야 하는 경우" 섹션으로 이동했습니다. 외부 API 소비자에서 피처 플래그를 사용하지 않기 # 피처 플래그는 내부 구현 세부 사항이며 공개 API 계약의 일부가 아닙니다. IDE 확장, Duo CLI, CI 통합처럼 GraphQL metadata.featureFlags 필드나 더 이상 사용되지 않는 featureFlagEnabled 필드로 피처 플래그를 조회하는 외부 API 소비자는 특정한 위험에 노출됩니다. 플래그가 모노리스에서 제거될 때 외부 소비자는 아직 업데이트되지 않았을 수 있으며, 그 영향은 사소한 UI 문제부터 고객에게 영향을 주는 인시던트까지 다양합니다. 외부 API 소비자에서 피처 플래그를 다룰 때는 다음 지침을 따릅니다. API 필드나 Application Settings를 우선합니다. 가능하면 외부 API 소비자에서 피처 플래그를 조회하지 않습니다. 대신 소비자가 조회할 수 있는 전용 API 필드나 Application Setting 을 도입합니다. 이 값들은 플래그가 제거된 뒤에도 유지됩니다. fail-open 동작을 구현합니다. 외부 API 소비자에서 피처 플래그를 반드시 사용해야 한다면 "fail-open" 메커니즘을 구현합니다. 롤아웃 마일스톤이 확정된 뒤에는 소비자가 플래그를 활성화된 것으로 간주하도록 기본값을 둡니다. 롤아웃 마일스톤이 확인되는 즉시 소비자를 업데이트합니다. GitLab Language Server의 예시 를 참고합니다. 제거 전에 사용자의 업그레이드 패턴을 고려합니다. 외부 API 소비자가 사용하는 플래그를 제거하기 전에 사용자가 클라이언트를 얼마나 빠르게 업데이트하는지 평가하고 가장 안전한 제거 시점을 결정합니다. 장기 설정에 피처 플래그를 사용하지 않기 # 피처 플래그는 짧은 기간만 유지하도록 설계되었습니다. 오랜 기간에 걸쳐 사용자·그룹·프로젝트 단위로 무언가를 활성화하기 위해 피처 플래그를 추가하려는 경우라면 대신 Cascading Settings 나 Application Settings 도입을 고려합니다. 설정은 고객이 GitLab.com 또는 Self-Managed