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 |
---|---|---|---|---|---|
implemented |
@ayufan
|
@glopezfernandez
|
@kencjohnston
@craig-gomes
| devops non_devops | 2020-06-10 |
개발 피처 플래그 아키텍처
피처 플래그의 사용은 GitLab의 개발에 중대한 역할을 합니다.
피처 플래그는 변경 사항을 조기에 적용하고 안전하게 널리 배포하는 편리한 방법이며, 해당 기능이 안정적이고 성능이 우수한지를 보장합니다.
기능이 전용 조건으로 제어되므로 개발자는 기능을 테스트하기에 가장 적합한 시기를 결정하여 해당 기능이 너리 시간 이전에 활성화되지 않도록 보장할 수 있습니다.
도전 과제
- 코드베이스에 추가하는 각 피처 플래그는 구성의 행렬을 추가하여 기술적 부채를 늘립니다.
- 피처 플래그의 각 조합을 테스트하는 것은 거의 불가능에 가깝기 때문에, 대신 가장 일반적인 시나리오에 맞게 피처 플래그를 테스트하는 것을 시도합니다.
- 피처 플래그의 수가 늘어남에 따라 유지하는 것이 점점 어려워지고 있습니다. 때로는 피처 플래그가 어떻게 구성되었는지 잊어버리거나 아직 피처 플래그를 제거하지 않은 이유를 잊을 수도 있습니다.
- 개발 외의 사람들에게 피처 플래그의 사용이 혼란스러울 수도 있습니다. 그들은 ~"type::feature" 또는 ~"type::bug" 수정이 피처 플래그에 어떻게 의존하며, 이 피처 플래그가 어떻게 구성되었는지 완전히 이해하지 못할 수 있습니다. 또는 해당 기능이 릴리스 포스트의 일부로 발표되어야 하는지 알지 못할 수도 있습니다.
- 피처 플래그를 유지하는 것은 테스트, 개발, 스테이징, 프로덕션 및 온프레미스 오퍼링의 다양한 환경/대상에 대한 다양한 구성을 관리해야 하는 추가적인 도전 과제를 야기합니다.
목표
오늘날의 가장 큰 도전 과제는 피처 플래그의 암묵적인 특성입니다. 피처 플래그는 코드베이스의 일부이며 개발 기능 밖에서 이해하기 어렵게 만듭니다.
우리의 목표는 모든 이해 관계자들이 피처 플래그 기반 개발에 쉽게 접근할 수 있도록 만드는 것입니다.
- 개발자 / 엔지니어
- 새로운 피처 플래그를 쉽게 추가하고 상태를 구성할 수 있습니다.
- 다른 피처 플래그를 변경하려면 누구에게 연락해야 하는지 빨리 찾을 수 있습니다.
- 있는지 모르는 피처 플래그를 빨리 찾을 수 있습니다.
- 엔지니어링 매니저
- 그룹이 관리하는 피처 플래그를 이해할 수 있습니다.
- 엔지니어링 매니저 및 디렉터
- 관리해야 하는 피처 플래그의 수가 유발하는 ~"technical debt"를 이해할 수 있습니다.
- 각 릴리스에서 추가되거나 제거된 피처 플래그의 수를 이해할 수 있습니다.
- 제품 매니저 및 문서 작성자
- 어떤 기능이 어떤 피처 플래그에 의해 제어되는지 이해할 수 있습니다.
- GitLab.com에서 기능과 관련된 피처 플래그가 일반적으로 사용 가능한지 이해할 수 있습니다.
- 온프레미스 설치의 경우 기능과 따라서 피처 플래그가 기본적으로 활성화되는지 이해할 수 있습니다.
- 전달 엔지니어
- 연이후 배포 사이에 도입된 피처 플래그가 어떻게 변경되었는지 이해할 수 있습니다.
- 지원 및 신뢰성 엔지니어
- 릴리스 간에 피처 플래그가 어떻게 변경되었는지 이해할 수 있으며, 활성화된 피처 플래그와 제거된 피처 플래그를 알 수 있습니다.
- 지원 요청 또는 사건 처리에 도움을 줄 수 있는 관련 정보를 빨리 찾을 수 있습니다.
제안
위의 목표를 달성하기 위해 피처 플래그의 사용을 명시적으로 이해 가능하도록 만들어야 합니다.
feature-flags/<name-of-feature.yml>
(이름-플래그.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:
및 다른actors
를 사용하여 피처 플래그를 모호하게 사용합니다. - 누가 어떤 피처 플래그를 소유하고 관련 정보를 찾을 수 있는 곳이 명확하게 표시되어 있지 않습니다.
- 피처 플래그 롤아웃 이슈를 생성하는 것이 필요하다는 명확한 표시가 없습니다.
- 정확히 어떤 피처 플래그가 우리 코드베이스에 있는지 알 수 없습니다.
- 다양한 환경에 대해 피처 플래그의 구성을 정확하게 알지 못합니다.
test
에 사용되는 것,온프레미스
에 제공되는 것,스테이징
,qa
,프로덕션
의 설정 등
수렴
이 작업은 전용 에픽의 일부로 진행되고 있습니다:
피처 플래그 내부 사용 개선.
이 에픽에서는 이러한 변경을 하는 메타 이유를 설명합니다.