특징 플래그

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 이동됨 13.5에 GitLab Premium에서 GitLab 무료로.

특징 플래그를 사용하면 애플리케이션의 새로운 기능을 작은 일괄로 본연의 환경에 배포할 수 있습니다. 특정 사용자 그룹에게 기능을 켜거나 끌 수 있어서 지속적인 전달을 달성하는 데 도움이 됩니다. 특징 플래그를 사용하면 통제된 테스트를 할 수 있고, 기능 전달과 고객 출시를 분리할 수 있어 위험을 줄이는 데 도움이 됩니다.

특징 플래그의 실제 작동 사례를 보려면 특징 플래그로 위험 제거하기를 참조하세요.

클릭하여 데모를 보려면 특징 플래그를 참조하세요.

note
GitLab 제품 개발에 기여하려면 이 특징 플래그 콘텐츠를 확인하세요.

작동 방식

GitLab은 특징 플래그를 위한 Unleash-호환 API를 제공합니다.

GitLab에서 플래그를 활성화하거나 비활성화함으로써 애플리케이션에서 어떤 기능을 활성화하거나 비활성화할지를 결정할 수 있습니다.

GitLab에서 특징 플래그를 생성하고 해당 상태를 가져오기 위해 애플리케이션에서 API를 사용할 수 있습니다. 애플리케이션은 GitLab과 통신하도록 구성되어야 하며 호환되는 클라이언트 라이브러리를 사용하고 앱에 특징 플래그를 통합하는지에 대한 여부는 개발자에 달려 있습니다.

특징 플래그 생성

특징 플래그를 생성하고 활성화하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 배포 > 특징 플래그을 선택합니다.
  3. 새 특징 플래그를 선택합니다.
  4. 첫 글자로 시작하고 소문자, 숫자, 밑줄(_), 또는 대시(-)만 포함하며 대시(-) 또는 밑줄(_)로 끝나지 않는 이름을 입력합니다.
  5. 선택 사항입니다. 설명을 입력합니다(최대 255자).
  6. Feature Flag Strategies를 추가하여 플래그가 어떻게 적용될지를 정의합니다. 각 전략에는 Type(기본값은 모든 사용자)와 환경(기본값은 모든 환경)을 포함합니다.
  7. 특징 플래그 생성을 선택합니다.

이러한 설정을 변경하려면 디렉터리에서 어떤 특징 플래그의 옆에 있는 편집 ()을 선택합니다.

최대 특징 플래그 수

Self-managed GitLab 인스턴스에서 프로젝트당 최대 특징 플래그 수는 200개입니다. GitLab SaaS의 경우 최대 수는 티어에 따라 결정됩니다:

티어 프로젝트당 특징 플래그 (SaaS) 프로젝트당 특징 플래그 (Self-managed)
무료 50 200
Premium 150 200
Ultimate 200 200

특징 플래그 전략

  • GitLab 13.0에서 도입됨.
  • 피처 플래그로 롤아웃, 기본적으로 비활성화되었습니다.
  • GitLab 13.2에서 기본으로 활성화되었습니다.
  • 운영 환경에서 권장됩니다.
  • GitLab.com에서 활성화되어 있습니다.

하나의 전략을 여러 환경에 걸쳐 적용할 수 있어서 특징 플래그 전략을 여러 번 정의하지 않아도 됩니다.

GitLab의 특징 플래그는 Unleash를 기반으로 합니다. Unleash에는 세분화된 피처 플래그 제어를 위한 전략가 있습니다. GitLab의 특징 플래그는 여러 전략을 가질 수 있으며 지원되는 전략은 다음과 같습니다:

전략은 특징 플래그를 생성하는 동안에 특징 플래그에 추가하거나, 생성 후에 배포 > 특징 플래그로 이동한 후 편집 ()을 선택하여 기존 특징 플래그를 편집하여 추가할 수 있습니다.

모든 사용자

모든 사용자를 위해 기능을 활성화합니다. 이는 표준(default) Unleash 활성화 전략을 사용합니다.

사용자의 퍼센트

GitLab 13.5에서 도입됨.

페이지 뷰의 백분율에 해당하는 기능을 활성화하며, 구성 가능한 일관성을 갖습니다. 이 일관성은 스티키니스로 알려져 있기도 합니다. 이는 Gradual Rollout (flexibleRollout) Unleash 활성화 전략를 사용합니다.

일관성은 다음을 기반으로 구성할 수 있습니다:

  • 사용자 ID: 각 사용자 ID에는 세션 ID를 무시하고 일관된 동작이 있습니다.
  • 세션 ID: 각 세션 ID에는 사용자 ID를 무시하고 일관된 동작이 있습니다.
  • 랜덤: 일관된 동작이 보장되지 않습니다. 기능은 페이지 뷰의 선택된 퍼센트에 대해 무작위로 활성화됩니다. 사용자 ID와 세션 ID를 무시합니다.
  • 사용 가능한 ID: 사용자의 상태에 따라 일관된 동작을 시도합니다:
    • 사용자가 로그인한 경우, 사용자 ID를 기반으로 일관된 동작을합니다.
    • 사용자가 익명이면 세션 ID를 기반으로 일관된 동작을합니다.
    • 사용자 ID나 세션 ID가 없는 경우 페이지 뷰의 선택된 퍼센트에 대해 기능을 무작위로 활성화합니다.

예를 들어, 사용 가능한 ID를 기준으로 15%의 값을 설정하여 페이지 뷰의 15%에 대한 기능을 활성화할 수 있습니다. 인증된 사용자에게는 사용자 ID를 기반으로 활성화되며, 세션 ID가 있는 익명 사용자에게는 세션 ID를 기반으로 활성화됩니다. 그리고 세션 ID가 제공되지 않으면 무작위로 활성화됩니다.

롤아웃의 백분율은 0%부터 100%까지입니다.

사용자 ID를 기반으로 일관성을 선택하는 것은 사용자의 퍼센트 롤아웃과 같은 방식으로 기능합니다.

caution
랜덤을 선택하면 개별 사용자에 대한 일관된 애플리케이션 동작이 제공되지 않습니다.

사용자의 비율

인증된 사용자의 퍼센트 중 일부 사용자용 기능을 활성화합니다. 이는 Unleash 활성화 전략인 gradualRolloutUserId을 사용합니다.

예를 들어, 인증된 사용자의 15%에게 기능을 활성화하려면 값으로 15%를 설정합니다.

Rollout 비율은 0%에서 100%까지 가능합니다.

익명 사용자가 아닌 경우 인증된 사용자의 경우 일관된 애플리케이션 동작이 보장되지만 익명 사용자의 경우는 그렇지 않습니다.

사용자 ID를 기반으로 한 일관성을 갖는 퍼센트 롤아웃은 동일한 동작을 합니다. 퍼센트 롤아웃을 사용하는 것을 권장합니다. 왜냐하면 사용자의 비율보다 더 유연하기 때문입니다.

caution
사용자의 비율 전략이 선택된 경우, Unleash 클라이언트에게 기능을 활성화하려면 반드시 사용자 ID를 제공해야 합니다. 아래의 루비 예제를 참조하십시오.

사용자 ID

대상 사용자 디렉터리에 대해 기능을 활성화합니다. 이는 Unleash UserIDs (userWithId) 활성화 전략를 사용하여 구현되었습니다.

사용자 ID를 쉼표로 구분된 값 디렉터리으로 입력합니다(예: user@example.com, user2@example.com, 또는 username1,username2,username3 등). 사용자 ID는 귀하의 애플리케이션 사용자를 위한 식별자입니다. 꼭 GitLab 사용자일 필요는 없습니다.

caution
대상 사용자를 위해 기능을 활성화하려면 Unleash 클라이언트에게 반드시 사용자 ID를 제공해야 합니다. 아래의 루비 예제를 참조하십시오.

사용자 디렉터리

피처 플래그 UI에서 생성된 사용자 디렉터리 또는 피처 플래그 사용자 디렉터리 API를 사용하여 기능을 활성화합니다. 사용자 ID와 유사하게 Unleash UsersIDs (userWithId) 활성화 전략을 사용합니다.

특정 사용자를 위해 특정 기능을 비활성화할 수는 없지만 사용자 디렉터리에 대해 기능을 활성화함으로써 유사한 결과를 얻을 수 있습니다.

예: - 전체 사용자 디렉터리 = User1A, User1B, User2A, User2B, User3A, User3B, ... - B 사용자를 제외한 전체 사용자 디렉터리 = User1A, User2A, User3A, ...

사용자 디렉터리 생성

사용자 디렉터리을 생성하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 사용자 디렉터리 보기를 선택합니다.
  4. 새로운 사용자 디렉터리을 선택합니다.
  5. 디렉터리의 이름을 입력합니다.
  6. 생성을 선택합니다.

디렉터리을 보면 편집 ()을 선택하여 디렉터리의 사용자 ID를 볼 수 있습니다. 디렉터리을 보는 동안 편집 ()을 선택하여 이름을 변경할 수 있습니다.

사용자를 사용자 디렉터리에 추가

사용자를 사용자 디렉터리에 추가하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 사용자를 추가하려는 디렉터리 옆의 편집 ()을 선택합니다.
  4. 사용자 추가를 선택합니다.
  5. 사용자 ID를 쉼표로 구분된 값 디렉터리으로 입력합니다. 예를 들어, user@example.com, user2@example.com, 또는 username1,username2,username3 등.
  6. 추가를 선택합니다.

사용자를 사용자 디렉터리에서 제거

사용자를 사용자 디렉터리에서 제거하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 변경하고자 하는 디렉터리 옆의 편집 ()을 선택합니다.
  4. 제거하려는 ID 옆의 제거 ()를 선택합니다.

코드 참조 검색

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

코드에서 피처 플래그를 정리하기 위해 해당 피처 플래그에 대한 프로젝트 참조를 찾습니다.

피처 플래그의 코드 참조를 검색하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 제거하려는 피처 플래그를 편집합니다.
  4. 더 많은 작업 ()을 선택합니다.
  5. 코드 참조 검색을 선택합니다.

특정 환경의 피처 플래그 비활성화

GitLab 13.0 및 이전 버전에서는 특정 환경의 피처 플래그를 비활성화하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 비활성화하려는 피처 플래그를 선택합니다.
  4. 플래그를 비활성화하려면:
    • GitLab 13.0 및 이전 버전: 환경의 상태 토글을 슬라이드합니다. 또는, 환경 사양을 삭제하려면 오른쪽에서 제거 (X)를 선택합니다.
    • GitLab 13.1 이상: 적용되는 각 전략에 대해 환경 하위에서 환경을 삭제합니다.
  5. 변경 사항 저장을 선택합니다.

모든 환경에서 피처 플래그 비활성화하기

모든 환경에서 피처 플래그를 비활성화하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 비활성화하려는 피처 플래그를 찾아서 상태 토글을 비활성화로 슬라이드합니다.

피처 플래그는 비활성화 탭에 표시됩니다.

애플리케이션과 피처 플래그 통합

애플리케이션에서 피처 플래그를 사용하려면 GitLab에서 액세스 자격 증명을 가져와야 합니다. 그런 다음 클라이언트 라이브러리를 사용하여 애플리케이션을 준비합니다.

액세스 자격 증명 가져오기

애플리케이션이 GitLab과 통신하기 위해 필요한 액세스 자격 증명을 가져오려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 배포 > 피처 플래그를 선택합니다.
  3. 다음을 보려면 구성을 선택합니다:
    • API URL: 클라이언트(애플리케이션)가 피처 플래그 디렉터리을 가져오기 위해 연결하는 URL
    • 인스턴스 ID: 피처 플래그 검색을 승인하는 고유 토큰

    • 애플리케이션 이름: 애플리케이션이 실행되는 환경의 이름 (애플리케이션이 실행되는 환경의 이름이며 애플리케이션 자체의 이름이 아님).

      예를 들어, 애플리케션이 프로덕션 서버에서 실행되는 경우, 애플리케이션 이름 은 production 또는 유사한 이름일 수 있습니다. 이 값은 환경 사양 평가에 사용됩니다.

이러한 필드의 의미는 시간이 지남에 따라 변경될 수 있습니다. 예를 들어, 인스턴스 ID가 환경에 할당된 단일 토큰인지 여러 토큰인지 확실하지 않습니다. 또한, 애플리케이션 이름이 실행 환경이 아닌 애플리케이션 버전을 설명할 수도 있습니다.

클라이언트 라이브러리 선택

GitLab은 Unleash 클라이언트와 호환되는 단일 백엔드를 구현합니다.

Unleash 클라이언트를 사용하면 개발자들은 애플리케이션 코드에서 플래그의 기본값을 정의할 수 있습니다. 각 피처 플래그 평가는 제공된 구성 파일에 플래그가 없는 경우 원하는 결과를 표현할 수 있습니다.

현재 Unleash는 다양한 언어 및 프레임워크용 많은 SDK를 제공하고 있습니다.

피처 플래그 API 정보

API 내용은 다음을 참조하십시오:

Go 애플리케이션 예시

다음은 Go 애플리케이션에서 피처 플래그를 통합하는 예시입니다: 

// 코드 예시는 여기에 들어갑니다

Ruby 애플리케이션 예시

다음은 Ruby 애플리케이션에서 피처 플래그를 통합하는 예시입니다: 

# 코드 예시는 여기에 들어갑니다

Unleash Proxy 예시

Unleash Proxy 버전 0.2 기준으로 프록시는 피처 플래그와 호환됩니다.

GitLab.com에서 프로덕션에 Unleash Proxy를 사용해야 합니다. 자세한 내용은 성능 노트를 참조하십시오.

프로젝트의 피처 플래그에 연결하려면 Docker 컨테이너를 실행하려면 다음 명령을 실행하십시오: 

// 명령어 예시는 여기에 들어갑니다
변수 값
UNLEASH_PROXY_SECRETS Unleash Proxy 클라이언트 구성에 사용되는 공유 비밀
UNLEASH_URL 프로젝트의 API URL. 자세한 내용은 액세스 자격 증명 가져오기를 참조하십시오.
UNLEASH_INSTANCE_ID 프로젝트의 인스턴스 ID. 자세한 내용은 액세스 자격 증명 가져오기를 참조하십시오.
UNLEASH_APP_NAME 애플리케이션이 실행되는 환경의 이름. 자세한 내용은 액세스 자격 증명 가져오기를 참조하십시오.
UNLEASH_API_TOKEN Unleash Proxy 시작에 필요하지만 GitLab에 연결하는 데 사용되지 않습니다. 아무 값으로 설정할 수 있습니다.

특징 플래그 관련 이슈

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

특징 플래그와 관련된 이슈를 링크할 수 있습니다. 특징 플래그의 연결된 이슈 섹션에서, + 버튼을 선택하고 이슈 참조 번호 또는 전체 이슈 URL을 입력하세요. 그럼 이슈가 관련 특징 플래그에 나타나며 그 반대로도 표시됩니다.

이 기능은 연결된 이슈 기능과 유사합니다.

성능 요소

GitLab 특징 플래그는 모든 애플리케이션에서 사용할 수 있습니다. 큰 애플리케이션은 고급 구성이 필요할 수 있습니다. 이 섹션에서는 특징을 사용하기 전에 조직이 필요한 것을 파악하는 데 도움이 되는 성능 요소를 설명합니다. 자세한 내용을 파악하려면 작동 방식 섹션을 먼저 읽으세요.

애플리케이션 노드에서 지원하는 최대 클라이언트

GitLab은 비율 제한에 도달할 때까지 가능한 한 많은 클라이언트 요청을 받습니다. 특징 플래그 API는 인증되지 않은 트래픽(특정 IP 주소에서)로 간주됩니다. GitLab.com의 경우, GitLab.com 특정 제한 사항을 참조하세요.

SDK에서 폴링 속도를 구성할 수 있습니다. 모든 클라이언트가 동일한 IP에서 요청하는 경우:

  • 분당 한 번 요청… 500개의 클라이언트를 지원할 수 있습니다.
  • 15초에 한 번 요청… 125개의 클라이언트를 지원할 수 있습니다.

더 확장 가능한 솔루션을 찾는 애플리케이션은 Unleash Proxy를 사용해야 합니다. GitLab.com의 경우, Unleash Proxy를 사용하여 엔드포인트 전체에 대한 비율 제한을 줄일 수 있습니다. 이 프록시 서버는 서버와 클라이언트 그룹 간의 중간에 위치하며, 클라이언트 그룹을 대신하여 서버로 요청을 만들어서 발신 요청 수를 크게 줄일 수 있습니다. 여전히 429 응답을 받으면 Unleash Proxy의 UNLEASH_FETCH_INTERVAL 값을 늘리세요.

현재 비율 제한에 더 많은 용량을 제공하기 위한 이슈도 있습니다.

네트워크 오류 복구

일반적으로 Unleash 클라이언트는 서버가 오류 코드를 반환할 때 폴백 메커니즘이 있습니다. 예를 들어, unleash-ruby-client는 애플리케이션이 현재 상태에서 계속 실행될 수 있도록 로컬 백업에서 플래그 데이터를 읽습니다.

자세한 정보는 SDK 프로젝트의 문서를 참조하세요.

Self-managed GitLab

기능적으로 차이점은 없습니다. SaaS와 Self-managed 둘 다 동일하게 작동합니다.

확장성 측면에서, GitLab 인스턴스의 사양에 달려 있습니다. 예를 들어, GitLab.com은 HA 아키텍처를 사용하여 많은 동시 요청을 처리할 수 있습니다. 그러나 성능을 비교할 수 있는 구동력이 약한 기계에 설치된 Self-managed 인스턴스는 해당하지 않습니다. 더 많은 정보는 참조 아키텍처를 참조하세요.