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.com 피처 플래그 상태 변경 문제: GitLab.com의 각 피처 플래그 상태 변경에 대해 이 프로젝트에 문제가 만들어집니다.
-
내부 GitLab.com 피처 플래그 상태 변경 로그:
source: feature
및env: gprd
로 로그 필터로 피처 플래그 상태 변경 로그를 볼 수 있습니다.
GitLab 엔지니어 및 인프라/품질 디렉터, 부사장 및 CTO
- 내부 Sisense 대시보드: 시간별 피처 플래그 메트릭, DevOps 그룹별로 그룹화됨.
GitLab 엔지니어 및 제품 매니저
- “주의가 필요한 피처 플래그” 월간 보고서: 위의 내부 Sisense 대시보드와 동일한 데이터지만 특정 DevOps 그룹에 대한 이슈에 제시되고 해당 그룹의 엔지니어 매니저에 할당됩니다.
피처 플래그 기본 상태를 확인하려는 사람들
- 비공식 피처 플래그 대시보드: 유용한 필터링을 제공하는 사용자 친화적인 대시보드.
이로 인해 거의 모든 피처 플래그 이해권자(개발 엔지니어, 엔지니어 관리자, 사이트 신뢰성, 제공 엔지니어)들에게 혼란을 야기합니다.
제안
피처 플래그 구현 및 사용 개선
-
구현 단계에서 잘못된 구성 및 인간 오류 가능성을 줄입니다
- “시간의 백분율” 전략을 “참가자의 백분율”로 대체합니다.
- 피처 플래그 개발 문서 개선
새로운 피처 플래그 유형
도입
개발
피처 플래그 유형은 실제로 여러 사용 사례를 포함한다는 것이 명백합니다.
- GitLab.com 배포 위험 완화. YAML 값:
gitlab_com_derisk
. - 진행 중인 기능. YAML 값:
wip
. 기능이 완전해지면, 여전히 기능의 확장성에 대한 몇 가지 의문이 있으면, 피처 플래그 유형을beta
로 변경할 수 있습니다. - 베타 기능. YAML 값:
beta
.
- 이러한 새로운 유형은 미래에 더 이상 사용하지 않아야 하는 넓은
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
피처 플래그 롤아웃 프로세스를 간소화
- (프로세스) Production issue tracker에서 롤아웃 이슈를 생성하고 Change management issue template에 더 가까운 템플릿으로 조정하세요(참고용 이슈도 함께 참고하세요). 이렇게 하면 롤아웃 이슈는 실제 프로덕션 변경 사항(예: 프로덕션에서의 플래그 활성화/비활성화)에 대해서만 관련되며, 프로덕션 변경이 예상대로 작동되면 이슈를 즉시 닫아야 합니다.
- (자동화) 대부분의 롤아웃 단계를 자동화하세요:
- (완료) 제출자에게 스테이징/캐너리/프로덕션 환경에 기능이 배포되었음을 알립니다
- (완료) 실제 피처 플래그 상태 변경(챗옵스 프로젝트에서)을 롤아웃 이슈에 크로스 링크합니다
- (완료)
default_enabled: true
MR이 프로덕션에 배포되었고 피처 플래그가 프로덕션에서 제거될 수 있다는 제출자에게 알립니다 - 피처 플래그가 처음으로 MR에 도입될 때 롤아웃 이슈를 생성하고
rollout_issue_url
필드를 채우는 차이 제안을 제공합니다 (Danger) - MR에서 피처 플래그 정의 제약 조건을 확인하고 강제합니다 (Danger)
- MR의
milestone
필드와 MR의 마일스톤 값이 다른 경우milestone
필드를 정정하는 차이 제안을 제공합니다 (Danger) - 피처 플래그 상태 변경 시, 해당하는 그룹에게 슬랙으로 알림 (챗옵스)
- 피처 플래그 최대 수명의 7일 전에 “정리 MR”을 자동으로 생성하고, 그룹 레이블을 설정하고, (아직 GitLab과 함께하는 경우) 피처 플래그 저자에 할당합니다. 반복적인 개발자 작업의 자동화를 활용할 수 있습니다.
- 섹션 수준에서 피처 플래그 최대 수명을 자동 보고 및 정기적 검토로 강제화합니다
- (문서/프로세스) 롤아웃 DRI가 피처 플래그를 활성화한 후 몇 시간 동안 온라인 상태를 유지 (이상적으로는 하루를 시작할 때 피처 플래그를 활성화해야 함)하여 피처 플래그에 문제가 발생할 경우를 대비합니다.
- (프로세스) 표준화된 롤아웃 단계를 제공합니다. 고려해야 할 점은 다음과 같습니다:
- 오류가 발생할 가능성
- 피처 플래그 롤아웃에 영향을 받는 총 사용자 수/요청/프로젝트/그룹 등, 예: 1%에 대한 롤아웃 시 10만 명의 사용자가 로그인할 수 없는 것은 나쁜 일입니다
- 각 단계 사이에 기다릴 시간. 일부 피처 플래그는 단계당 10분을 기다려야 하지만, 일부 플래그는 24시간을 기다려야 합니다. 이상적으로는 각 단계에 대해 부정적인 영향이 없는지 적극적으로 확인하는 자동화가 있어야 합니다.
GitLab.com에서 피처 플래그의 기본 상태 및 현재 상태 및 상태 변경에 대한 더 나은 SSOT 제공
GitLab 고객
- 사용자 설명서: 현재 페이지를 유지하되, 비공식 피처 플래그 대시 보드처럼 필터링과 정렬을 추가하세요.
사이트 신뢰성 및 배송 엔지니어
우리는 피처 플래그 상태 변경 로깅 전략의 유용성을 평가했습니다 내부 GitLab.com 피처 플래그 상태 변경 이슈와 내부 GitLab.com 피처 플래그 상태 변경 로그가 서로 다른 관객들에게 유용한 것으로 나타났습니다.
GitLab 엔지니어 및 인프라/품질 이사/부사장 및 CTO
- 내부 Sisense 대시보드: 현재 대시보드를 해당 이해 관계자에게 보다 유용하도록 간소화하세요.
GitLab 엔지니어 및 제품 관리자
- “주목이 필요한 피처 플래그” 월간 보고서: 현재 보고서를 피처 플래그 제거를 위한 자동 생성된 MR에 링크하고 피처 플래그에 대한 문서화 및 모범 사례를 개선하여 더욱 유용하게 만드세요.
반복
이 작업은 피처 플래그의 내부 사용 개선의 일환으로 진행됩니다. 이 Epic은 이러한 변경 사항을 위한 메타 이유를 설명합니다.