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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
implemented	`@ayufan`	`@glopezfernandez`	`@kencjohnston` `@craig-gomes`	devops non_devops	2020-06-10

개발 기능 플래그 아키텍처

기능 플래그의 사용은 GitLab의 개발에 있어 중요합니다. 기능 플래그는 변경 사항을 빨리 배포하고 안정적으로 전체 사용자에게 롤아웃할 수 있는 편리한 방법입니다.

특정 조건으로 기능의 존재가 제어되므로 개발자는 기능을 테스트하는 가장 적절한 시기를 결정할 수 있으며, 기능이 조기에 활성화되지 않도록 보장할 수 있습니다.

도전과제

기능 플래그의 광범위한 사용은 몇 가지 도전과제가 있습니다.

코드베이스에 추가하는 각 기능 플래그는 구성 요소의 매트릭스를 추가하는 것으로 기술적 부채를 의미합니다.
각 기능 플래그의 조합을 테스트하는 것은 거의 불가능에 가깝기 때문에, 대신 가장 일반적인 시나리오에 대한 기능 플래그의 테스트를 최적화하려고 합니다.
점점 더 많아지는 기능 플래그를 유지하는 것이 점점 더 어려워지고 있습니다. 때로는 왜 기능 플래그를 제거하지 않았는지 혹은 기능 플래그가 어떻게 구성되어 있는지 잊어버릴 수 있습니다.
개발 밖에서 기능 플래그의 사용은 혼란스러울 수 있습니다. 이러한 경우, “type::feature”나 “type::bug” 수정에 대한 기능 플래그의 의존성을 완전히 이해하지 못할 수 있으며, 이 기능 플래그가 어떻게 구성되었는지, 릴리스 후에 이 기능이 공개되어야 하는지 여부를 이해할 수 없을 수 있습니다.
기능 플래그를 유지하는 것은 다른 환경/대상에 대한 다른 구성을 관리해야 하는 추가 도전과제를 야기시킵니다. 테스트, 개발, 스테이징, 프로덕션을 위한 기능 플래그의 다른 구성 및 온프레미스 오퍼링의 일환으로 고객에게 제공되는 내용에 대한 기능 플래그의 다른 구성을 관리해야 합니다.

목표

오늘날 우리의 기능 플래그 사용에서 가장 큰 도전 과제는 그들의 내제적인 성격입니다. 기능 플래그는 코드베이스의 일부이며, 이를 이해하기 어렵게 만듭니다.

우리는 우리의 기능 플래그 기반 개발을 관심 있는 모든 당사자들이 접근할 수 있도록 만들어야 합니다.

개발자 / 엔지니어
- 새로운 기능 플래그를 쉽게 추가하고 구성할 수 있어야 합니다.
- 다른 기능 플래그에 영향을 미치는 경우 빠르게 담당자를 찾을 수 있어야 합니다.
- 오래된 기능 플래그를 빨리 찾을 수 있어야 합니다.
엔지니어링 매니저
- 그녀/그의 그룹이 관리하는 기능 플래그를 이해할 수 있어야 합니다.
엔지니어링 매니저와 디렉터
- 우리가 관리해야 하는 기능 플래그의 양으로 인해 얼마나 많은 기술적 부채가 발생하는지 이해할 수 있어야 합니다.
- 각 릴리스마다 몇 개의 기능 플래그가 추가되었고 제거되었는지 이해할 수 있어야 합니다.
제품 매니저 및 문서 작성자
- 어떤 기능이 어떤 기능 플래그에 의해 제한되는지 이해해야 합니다.
- GitLab.com에서 기능이 일반적으로 사용 가능한지 이해해야 합니다.
- 온프레미스 설치의 기본값으로 기능과 따라서 기능 플래그가 활성화되는지 이해해야 합니다.
배포 엔지니어
- 연속적인 배포 간에 도입 및 변경된 기능 플래그를 이해해야 합니다.
지원 및 신뢰성 엔지니어
- 릴리스 간에 기능 플래그가 어떻게 변경되었는지 이해해야 합니다: 어떤 기능 플래그가 활성화되었고 무엇이 제거되었는지
- 현재 진행 중인 지원 요청이나 사건에 도움을 줄 수 있는 개인을 알아내기 위해 빠르게 관련 정보를 찾을 수 있어야 합니다.

제안

위의 목표를 달성하기 위해, 기능 플래그 사용을 명시적으로 만들고 모든 관련 당사자가 이해할 수 있도록 노력해야 합니다.

feature-flags/<name-of-feature.yml>라는 YAML로 설명된 기능 플래그를 도입함으로써, 다음과 같은 기능을 가질 수 있도록 해야 합니다:

모든 기능 플래그가 문서화된 중앙 장소,
왜 특정 기능 플래그가 도입되었는지에 대한 설명,
해당 기능 플래그가 도입된 관련 이슈와 머지 요청,
코드베이스의 모든 기능 플래그를 자동으로 문서화,
주어진 그룹 당 몇 개의 기능 플래그가 있는지 추적
릴리스 간에 추가되거나 제거된 기능 플래그의 수를 추적
이 정보를 모든 사람이 쉽게 액세스할 수 있도록 함
고객이 쉽게 기능을 활성화하고 다른 릴리스 간에 변경된 정보를 빨리 찾을 수 있도록 함

`YAML`

---
name: ci_disallow_to_create_merge_request_pipelines_in_target_project
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40724
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/235119
group: group::environments
type: development
default_enabled: false

이유

이러한 변경이 필요한 이유는 다음과 같습니다:

오늘날 우리는 약 500가지 다른 기능 플래그가 있습니다.
그들의 사용을 추적하는 데 어려움이 있습니다.
각기 다른 default_enabled: 및 다른 사용자를 사용하여 기능 플래그를 모호하게 사용하고 있습니다.
누가 어떤 기능 플래그를 소유하고 있는지, 관련 정보를 찾을 수 있는 곳이 어디인지 명확한 표시가 없습니다.
기능 플래그가 사실은 기술적 부채임을 나타내기 위해 기능 플래그 롤아웃 이슈를 생성할 욕구를 강조하지 않습니다.
우리는 정확히 우리의 코드베이스에 어떤 기능 플래그가 있는지 모릅니다.
우리는 다른 환경에 대해 우리의 기능 플래그가 어떻게 구성되어 있는지 정확히 알지 못합니다. test에 사용되는 것은 무엇이며, 온프레미스에 제공하는 것은 무엇이며, 스테이징, qa, 프로덕션에 대한 설정은 무엇인지 정확히 알지 못합니다.

반복

이 작업은 전용 에픽의 일환으로 수행됩니다: 기능 플래그의 내부 사용 향상. 이 에픽은 이러한 변경을 만드는 데 대한 메타 이유를 설명합니다.