• 도전 과제
• 목표
• 제안
  • YAML
• Reasons
• 반복

개발 피처 플래그 아키텍처

피처 플래그의 사용은 GitLab의 개발에 중요해졌습니다. 피처 플래그는 변경 사항을 빨리 적용하고 안정적으로 널리 배포하는 편리한 방법이며, 기능이 안정적이고 성능이 좋은지 보장합니다.

기능이 전용 조건으로 제어되므로 개발자는 기능을 테스트할 가장 적합한 시간을 결정하여 기능이 너리 서두르게 활성화되지 않도록 보장할 수 있습니다.

도전 과제

• 우리가 코드베이스에 추가하는 각 피처 플래그는 구성 행렬을 추가하여 ~"기술부채"입니다.
• 피처 플래그의 각 조합을 테스트하는 것은 거의 불가능하므로 대신 일반적인 시나리오에 대한 피처 플래그의 테스트를 최적화하려고 노력합니다.
• 계속해서 증가하는 피처 플래그의 유지 관리에 대한 도전 과제가 있습니다. 때로는 피처 플래그가 어떻게 구성되었는지 또는 아직 피처 플래그를 제거하지 않은 이유를 잊어버립니다.
• 개발 외부의 사람들에게 피처 플래그의 사용은 혼란스러울 수도 있으며, 해당 피처 플래그에 대한 ~"type::feature" 또는 ~"type::bug" 수정의 의존성을 완전히 이해하지 못할 수도 있습니다. 또는 기능이 릴리스 게시물의 일부로 발표되어야 하는지 여부입니다.
• 피처 플래그의 유지 관리는 테스트, 개발, 스테이징, 프로덕션 및 온프레미스 오퍼링의 다양한 환경/대상을 관리해야 하는 추가 도전 과제를 발생시킵니다.

목표

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

우리는 관심 있는 모든 당사자가 사용할 수 있도록 피처 플래그 기반 개발이 가능하도록 목표를 가져야 합니다.

• 개발자 / 엔지니어
  • 새로운 피처 플래그를 쉽게 추가하고 구성 상태를 설정할 수 있습니다.
  • 다른 피처 플래그에 대해 손을 대면 빨리 누구에게 연락할지 찾을 수 있습니다.
  • 오래된 피처 플래그를 빨리 찾을 수 있습니다.
• 엔지니어링 매니저
  • 자신의 그룹이 관리하는 피처 플래그를 이해할 수 있습니다.
• 엔지니어링 매니저 및 디렉터
  • 우리가 관리해야 하는 피처 플래그의 양으로 인해 발생하는 ~"기술부채"를 이해할 수 있습니다.
  • 각 릴리스마다 추가된 피처 플래그의 수와 삭제된 피처 플래그의 수를 이해할 수 있습니다.
• 제품 매니저 및 문서 작성자
  • 어떤 기능이 어떤 피처 플래그에 의해 제한되는지 이해할 수 있습니다.
  • GitLab.com에서 기능 및 해당 피처 플래그이 제공 가능한지 이해할 수 있습니다.
  • 온프레미스 설치에 대해 기능 및 해당 피처 플래그이 기본적으로 활성화되는지 이해할 수 있습니다.
• 전달 엔지니어
  • 연이은 배포 사이에 도입 및 변경된 피처 플래그를 이해할 수 있습니다.
• 지원 및 신뢰성 엔지니어
  • 릴리스 사이에 피처 플래그가 어떻게 변하는지 이해할 수 있습니다: 어떤 피처 플래그가 활성화되고 어떤 것이 제거되었는지를 빨리 찾을 수 있습니다.
  • 지속적인 지원 요청 또는 사건에 도움을 줄 수 있는 개인을 알기 위해 관련 정보를 빨리 찾을 수 있습니다.

제안

위의 목표를 달성하기 위해 피처 플래그 사용을 명확하게하고 관련된 모든 당사자에게 명확하게 이해되도록하는 것을 목표로 해야 합니다.

feature-flags/<name-of-feature.yml>로 설명된 YAML을 도입하여:

1. 모든 피처 플래그가 문서화된 중앙 위치
2. 주어진 피처 플래그가 도입된 이유에 대한 설명
3. 해당 피처 플래그가 도입된 관련 이슈 및 합병 요청
4. 코드베이스의 모든 피처 플래그가 포함된 자동화된 문서 작성
5. 주어진 그룹당 피처 플래그의 수를 추적
6. 릴리스간에 추가되고 제거된 피처 플래그의 수를 추적
7. 모든 사람들이 이 정보에 쉽게 액세스할 수 있도록 함
8. 우리 고객이 기능을 쉽게 활성화하고 다른 릴리스 간에 변경된 정보를 빨리 찾을 수 있도록 함

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

Reasons

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

• 오늘날 우리에는 약 500가지 다른 피처 플래그가 있습니다.
• 우리는 그들의 사용을 추적하는 데 어려움을 겪고 있습니다.
• 서로 다른 default_enabled: 및 서로 다른 actors를 사용하여 피처 플래그를 모호하게 사용하고 있습니다.
• 누가 어떤 피처 플래그를 소유하고 관련 정보를 찾을 장소를 명확히 표시하지 않습니다.
• 피처 플래그를 만들기 위한 롤아웃 이슈를 생성하는 데 대한 명확한 표시가 부족하여 피처 플래그가 실제로 ~"기술부채"임을 나타내지 않습니다.
• 코드베이스에 정확히 어떤 피처 플래그가 있는지 모릅니다.
• 다양한 환경에 대해 피처 플래그가 어떻게 구성되어 있는지 정확히 모르고 있습니다: 테스트에 사용되는 것, 온프레미스로 배송되는 것, 스태이징, QA, 프로덕션에 대한 설정은 어떤 것인지 명확히 모르고 있습니다.

반복

이 작업은 전용 에픽의 일부로 수행되고 있습니다: 피처 플래그 내부 사용 향상. 이 에픽은 이러한 변경을 만드는 메타 이유를 설명합니다.