기능 플래그
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
기능 플래그를 사용하면 애플리케이션의 새 기능을 프로덕션에 더 작은 단위로 배포할 수 있습니다. GitLab의 기능 플래그 전체 목록도 확인할 수 있습니다. 기능 플래그의 실제 예시는 기능 플래그로 위험 제거하기를 참조하십시오.
기능 플래그를 사용하면 애플리케이션의 새 기능을 프로덕션에 더 작은 단위로 배포할 수 있습니다. 사용자 하위 집합에 대해 기능을 켜고 끌 수 있어 지속적 배포를 달성하는 데 도움이 됩니다. 기능 플래그는 제어된 테스트를 수행하고 기능 제공과 고객 론칭을 분리하여 위험을 줄이는 데 도움이 됩니다.
GitLab의 기능 플래그 전체 목록도 확인할 수 있습니다.
기능 플래그의 실제 예시는 기능 플래그로 위험 제거하기를 참조하십시오.
클릭 데모는 기능 플래그를 참조하십시오.
기능 플래그 사용#
GitLab은 기능 플래그용 Unleash 호환 API를 제공합니다.
GitLab에서 플래그를 활성화하거나 비활성화하면 애플리케이션이 활성화 또는 비활성화할 기능을 결정할 수 있습니다.
GitLab에서 기능 플래그를 생성하고 애플리케이션의 API를 사용하여 기능 플래그 목록과 상태를 가져올 수 있습니다. 애플리케이션이 GitLab과 통신하도록 구성되어야 하므로 개발자가 호환 클라이언트 라이브러리를 사용하고 앱에 기능 플래그를 통합하는 것은 개발자의 몫입니다.
기능 플래그 생성#
기능 플래그를 생성하고 활성화하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 새 기능 플래그를 선택합니다.
- 문자로 시작하며 소문자, 숫자, 밑줄(
_) 또는 대시(-)만 포함하고 대시(-) 또는 밑줄(_)로 끝나지 않는 이름을 입력합니다. - 선택 사항. 설명을 입력합니다(최대 255자).
- 플래그 적용 방법을 정의하는 기능 플래그 전략을 추가합니다. 각 전략에 대해 유형(기본값은 모든 사용자)과 환경(기본값은 모든 환경)을 포함합니다.
- 기능 플래그 생성을 선택합니다.
이 설정을 변경하려면 목록의 기능 플래그 옆에서 편집 (✏️)을 선택합니다.
기능 플래그 최대 수#
GitLab Self-Managed에서 프로젝트당 기능 플래그의 최대 수는 200개입니다. GitLab.com의 경우 최대 수는 티어에 따라 결정됩니다:
| 티어 | 프로젝트당 기능 플래그 (GitLab.com) | 프로젝트당 기능 플래그 (GitLab Self-Managed) |
|---|---|---|
| Free | 50 | 200 |
| Premium | 150 | 200 |
| Ultimate | 200 | 200 |
기능 플래그 전략#
여러 환경에 걸쳐 기능 플래그 전략을 적용할 수 있으며, 전략을 여러 번 정의할 필요가 없습니다.
GitLab 기능 플래그는 Unleash를 기반으로 합니다. Unleash에는 세밀한 기능 플래그 제어를 위한 전략이 있습니다. GitLab 기능 플래그는 여러 전략을 가질 수 있으며, 지원되는 전략은 다음과 같습니다:
전략은 기능 플래그 생성 시 추가하거나, 배포 > 기능 플래그로 이동하여 편집 (✏️)을 선택하여 기존 기능 플래그를 편집하여 추가할 수 있습니다.
모든 사용자#
모든 사용자에 대해 기능을 활성화합니다. Standard(default) Unleash 활성화 전략을 사용합니다.
비율 롤아웃#
구성 가능한 동작 일관성으로 페이지 뷰의 비율에 대해 기능을 활성화합니다. 이 일관성은 고착성(stickiness)이라고도 합니다. Gradual Rollout(flexibleRollout) Unleash 활성화 전략을 사용합니다.
다음을 기반으로 일관성을 구성할 수 있습니다:
- 사용자 ID: 각 사용자 ID는 세션 ID를 무시하고 일관된 동작을 합니다.
- 세션 ID: 각 세션 ID는 사용자 ID를 무시하고 일관된 동작을 합니다.
- 무작위: 일관된 동작이 보장되지 않습니다. 기능이 임의로 선택된 페이지 뷰 비율에 대해 활성화됩니다. 사용자 ID와 세션 ID는 무시됩니다.
- 사용 가능한 ID: 사용자 상태에 따라 일관된 동작이 시도됩니다:
- 사용자가 로그인한 경우, 사용자 ID를 기반으로 동작을 일관되게 합니다.
- 사용자가 익명인 경우, 세션 ID를 기반으로 동작을 일관되게 합니다.
- 사용자 ID 또는 세션 ID가 없는 경우, 기능이 임의로 선택된 페이지 뷰 비율에 대해 활성화됩니다.
예를 들어, 사용 가능한 ID를 기반으로 15% 값을 설정하면 페이지 뷰의 15%에 대해 기능이 활성화됩니다. 인증된 사용자의 경우 사용자 ID를 기반으로 합니다. 사용자 ID가 없는 세션 ID가 있는 익명 사용자의 경우 세션 ID를 기반으로 합니다. 세션 ID가 없는 경우 무작위로 대체됩니다.
롤아웃 비율은 0%에서 100%까지 가능합니다.
사용자 ID를 기반으로 한 일관성 선택은 사용자 비율 롤아웃과 동일하게 동작합니다.
무작위 선택은 개별 사용자에 대해 일관되지 않은 애플리케이션 동작을 제공합니다.
사용자 비율#
인증된 사용자의 비율에 대해 기능을 활성화합니다. Unleash 활성화 전략 gradualRolloutUserId를 사용합니다.
예를 들어, 15% 값을 설정하면 인증된 사용자의 15%에 대해 기능이 활성화됩니다.
롤아웃 비율은 0%에서 100%까지 가능합니다.
고착성(동일 사용자에 대한 일관된 애플리케이션 동작)은 인증된 사용자에게는 보장되지만 익명 사용자에게는 보장되지 않습니다.
사용자 ID를 기반으로 한 일관성의 비율 롤아웃은 동일하게 동작합니다. 비율 롤아웃이 사용자 비율보다 더 유연하므로 비율 롤아웃을 사용해야 합니다.
사용자 비율 전략을 선택하면 Unleash 클라이언트가 기능을 활성화하기 위해 반드시 사용자 ID를 제공해야 합니다. 아래 Ruby 예시를 참조하십시오.
사용자 ID#
대상 사용자 목록에 대해 기능을 활성화합니다. Unleash UserIDs(userWithId) 활성화 전략을 사용하여 구현됩니다.
사용자 ID를 쉼표로 구분된 값의 목록으로 입력합니다(예: user@example.com, user2@example.com 또는 username1,username2,username3 등). 사용자 ID는 애플리케이션 사용자의 식별자입니다. GitLab 사용자일 필요는 없습니다.
Unleash 클라이언트가 대상 사용자에 대해 기능을 활성화하려면 반드시 사용자 ID를 제공해야 합니다. 아래 Ruby 예시를 참조하십시오.
사용자 목록#
기능 플래그 UI에서 생성하거나 기능 플래그 사용자 목록 API를 통해 생성된 사용자 목록에 대해 기능을 활성화합니다. 사용자 ID와 유사하게 Unleash UsersIDs(userWithId) 활성화 전략을 사용합니다.
특정 사용자에 대해 기능을 비활성화할 수는 없지만, 사용자 목록에 대해 활성화하여 유사한 결과를 달성할 수 있습니다.
예를 들어:
Full-user-list=User1A, User1B, User2A, User2B, User3A, User3B, ...Full-user-list-excluding-B-users=User1A, User2A, User3A, ...
사용자 목록 생성#
사용자 목록을 생성하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 사용자 목록 보기를 선택합니다.
- 새 사용자 목록을 선택합니다.
- 목록의 이름을 입력합니다.
- 생성을 선택합니다.
목록의 사용자 ID를 보려면 목록 옆의 편집 (✏️)을 선택합니다. 목록을 볼 때 편집 (✏️)을 선택하여 이름을 변경할 수 있습니다.
사용자 목록에 사용자 추가#
사용자 목록에 사용자를 추가하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 사용자를 추가할 목록 옆의 편집 (✏️)을 선택합니다.
- 사용자 추가를 선택합니다.
- 사용자 ID를 쉼표로 구분된 값의 목록으로 입력합니다. 예:
user@example.com, user2@example.com또는username1,username2,username3등. - 추가를 선택합니다.
사용자 목록에서 사용자 제거#
사용자 목록에서 사용자를 제거하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 변경하려는 목록 옆의 편집 (✏️)을 선택합니다.
- 제거할 ID 옆의 제거 ([remove])를 선택합니다.
코드 참조 검색#
정리 중에 코드에서 기능 플래그를 제거하려면 프로젝트 참조를 찾습니다.
기능 플래그의 코드 참조를 검색하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 제거하려는 기능 플래그를 편집합니다.
- 추가 작업 (⋮)을 선택합니다.
- 코드 참조 검색을 선택합니다.
특정 환경에 대한 기능 플래그 비활성화#
특정 환경에 대한 기능 플래그를 비활성화하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 비활성화할 기능 플래그에 대해 편집 (✏️)을 선택합니다.
- 플래그를 비활성화하려면:
- 적용되는 각 전략에 대해 환경 아래에서 환경을 삭제합니다.
- 변경 사항 저장을 선택합니다.
모든 환경에 대한 기능 플래그 비활성화#
모든 환경에 대한 기능 플래그를 비활성화하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 비활성화할 기능 플래그에 대해 상태 토글을 비활성화됨으로 밉니다.
기능 플래그가 비활성화됨 탭에 표시됩니다.
애플리케이션에 기능 플래그 통합#
애플리케이션과 함께 기능 플래그를 사용하려면 GitLab에서 액세스 자격 증명을 가져온 다음 클라이언트 라이브러리로 애플리케이션을 준비합니다.
액세스 자격 증명 가져오기#
애플리케이션이 GitLab과 통신하는 데 필요한 액세스 자격 증명을 가져오려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 구성을 선택하여 다음을 확인합니다:
-
API URL: 클라이언트(애플리케이션)가 기능 플래그 목록을 가져오기 위해 연결하는 URL.
-
인스턴스 ID: 기능 플래그 검색을 인증하는 고유 토큰.
-
애플리케이션 이름: 애플리케이션이 실행되는 환경의 이름 (애플리케이션 자체의 이름이 아님).
예를 들어, 애플리케이션이 프로덕션 서버에서 실행되는 경우 애플리케이션 이름은
production또는 유사한 값이 될 수 있습니다. 이 값은 환경 사양 평가에 사용됩니다.
-
이 필드의 의미는 시간이 지남에 따라 변경될 수 있습니다. 예를 들어, 인스턴스 ID는 단일 토큰이거나 환경에 할당된 여러 토큰일 수 있습니다. 또한 애플리케이션 이름은 실행 중인 환경 대신 애플리케이션 버전을 설명할 수 있습니다.
클라이언트 라이브러리 선택#
GitLab은 Unleash 클라이언트와 호환되는 단일 백엔드를 구현합니다.
Unleash 클라이언트를 사용하면 개발자는 애플리케이션 코드에서 플래그의 기본값을 정의할 수 있습니다. 각 기능 플래그 평가는 제공된 구성 파일에 플래그가 없는 경우 원하는 결과를 표현할 수 있습니다.
Unleash는 현재 다양한 언어 및 프레임워크를 위한 많은 SDK를 제공합니다.
기능 플래그 API 정보#
API 내용은 다음을 참조하십시오:
Go 애플리케이션 예시#
다음은 Go 애플리케이션에서 기능 플래그를 통합하는 방법의 예시입니다:
package main
import (
"io"
"log"
"net/http"
"github.com/Unleash/unleash-client-go/v3"
)
type metricsInterface struct {
}
func init() {
unleash.Initialize(
unleash.WithUrl("https://gitlab.com/api/v4/feature_flags/unleash/42"),
unleash.WithInstanceId("29QmjsW6KngPR5JNPMWx"),
unleash.WithAppName("production"), // Set to the running environment of your application
unleash.WithListener(&metricsInterface{}),
)
}
func helloServer(w http.ResponseWriter, req *http.Request) {
if unleash.IsEnabled("my_feature_name") {
io.WriteString(w, "Feature enabled\n")
} else {
io.WriteString(w, "hello, world!\n")
}
}
func main() {
http.HandleFunc("/", helloServer)
log.Fatal(http.ListenAndServe(":8080", nil))
}
Ruby 애플리케이션 예시#
다음은 Ruby 애플리케이션에서 기능 플래그를 통합하는 방법의 예시입니다.
Unleash 클라이언트에는 로그인 사용자 비율 롤아웃 전략 또는 대상 사용자 목록과 함께 사용할 사용자 ID가 제공됩니다.
#!/usr/bin/env ruby
require 'unleash'
require 'unleash/context'
unleash = Unleash::Client.new({
url: 'http://gitlab.com/api/v4/feature_flags/unleash/42',
app_name: 'production', # Set to the running environment of your application
instance_id: '29QmjsW6KngPR5JNPMWx'
})
unleash_context = Unleash::Context.new
# Replace "123" with the ID of an authenticated user.
# The context's user ID must be a string:
# https://unleash.github.io/docs/unleash_context
unleash_context.user_id = "123"
if unleash.is_enabled?("my_feature_name", unleash_context)
puts "Feature enabled"
else
puts "hello, world!"
end
Unleash 프록시 예시#
Unleash 프록시 버전 0.2부터 프록시가 기능 플래그와 호환됩니다.
GitLab.com 프로덕션에는 Unleash 프록시를 사용해야 합니다. 자세한 내용은 성능 참고사항을 참조하십시오.
프로젝트의 기능 플래그에 연결하는 Docker 컨테이너를 실행하려면 다음 명령을 실행합니다:
docker run \
-e UNLEASH_PROXY_SECRETS=<secret> \
-e UNLEASH_URL=<project feature flags URL> \
-e UNLEASH_INSTANCE_ID=<project feature flags instance ID> \
-e UNLEASH_APP_NAME=<project environment> \
-e UNLEASH_API_TOKEN=<tokenNotUsed> \
-p 3000:3000 \
unleashorg/unleash-proxy
| 변수 | 값 |
|---|---|
UNLEASH_PROXY_SECRETS |
Unleash 프록시 클라이언트를 구성하는 데 사용되는 공유 비밀. |
UNLEASH_URL |
프로젝트의 API URL. 자세한 내용은 액세스 자격 증명 가져오기를 참조하십시오. |
UNLEASH_INSTANCE_ID |
프로젝트의 인스턴스 ID. 자세한 내용은 액세스 자격 증명 가져오기를 참조하십시오. |
UNLEASH_APP_NAME |
애플리케이션이 실행되는 환경의 이름. 자세한 내용은 액세스 자격 증명 가져오기를 참조하십시오. |
UNLEASH_API_TOKEN |
Unleash 프록시를 시작하는 데 필요하지만 GitLab에 연결하는 데는 사용되지 않음. 임의의 값으로 설정할 수 있음. |
Unleash 프록시를 사용할 때 각 프록시 인스턴스는 UNLEASH_APP_NAME에 명명된 환경의 플래그만 요청할 수 있다는 제한이 있습니다. 프록시는 이를 클라이언트를 대신하여 GitLab에 전송하므로 클라이언트가 이를 재정의할 수 없습니다.
기능 플래그 관련 이슈#
기능 플래그에 관련 이슈를 연결할 수 있습니다. 기능 플래그의 연결된 이슈 섹션에서 + 버튼을 선택하고 이슈 참조 번호 또는 이슈의 전체 URL을 입력합니다. 그러면 이슈가 관련 기능 플래그와 그 반대 방향으로 나타납니다.
이 기능은 연결된 이슈 기능과 유사합니다.
성능 요소#
GitLab 기능 플래그는 모든 애플리케이션에서 사용할 수 있습니다. 대규모 애플리케이션에는 고급 구성이 필요할 수 있습니다. 이 섹션에서는 기능을 사용하기 전에 조직에서 수행해야 할 사항을 파악하는 데 도움이 되는 성능 요소에 대해 설명합니다. 자세한 내용은 기능 플래그 사용을 참조하십시오.
애플리케이션 노드에서 지원되는 최대 클라이언트 수#
GitLab은 속도 제한에 도달할 때까지 가능한 한 많은 클라이언트 요청을 수락합니다. 기능 플래그 API는 **인증되지 않은 트래픽(지정된 IP 주소에서)**으로 간주됩니다. GitLab.com의 경우 GitLab.com 특정 제한을 참조하십시오.
폴링 속도는 SDK에서 구성할 수 있습니다. 모든 클라이언트가 동일한 IP에서 요청하는 경우:
- 분당 1회 요청 ... 500개 클라이언트를 지원할 수 있음.
- 15초당 1회 요청 ... 125개 클라이언트를 지원할 수 있음.
더 확장 가능한 솔루션을 원하는 애플리케이션의 경우 Unleash 프록시를 사용해야 합니다. GitLab.com에서는 엔드포인트 전반에 걸쳐 속도 제한을 받을 가능성을 줄이기 위해 Unleash 프록시를 사용해야 합니다. 이 프록시 서버는 서버와 클라이언트 사이에 위치합니다. 클라이언트 그룹을 대신하여 서버에 요청하므로 아웃바운드 요청 수를 크게 줄일 수 있습니다. 여전히 429 응답을 받는 경우 Unleash 프록시의 UNLEASH_FETCH_INTERVAL 값을 늘리십시오.
현재 속도 제한에 더 많은 용량을 제공하기 위한 이슈도 있습니다.
네트워크 오류에서 복구#
일반적으로 Unleash 클라이언트는 서버가 오류 코드를 반환할 때 대체 메커니즘을 가지고 있습니다. 예를 들어, unleash-ruby-client는 로컬 백업에서 플래그 데이터를 읽어 애플리케이션이 현재 상태에서 계속 실행될 수 있습니다.
자세한 내용은 SDK 프로젝트의 문서를 참조하십시오.
GitLab Self-Managed#
기능적으로는 차이가 없습니다. GitLab.com과 GitLab Self-Managed는 동일하게 동작합니다.
확장성 측면에서는 GitLab 인스턴스의 사양에 따라 달라집니다. 예를 들어, GitLab.com은 HA 아키텍처를 사용하므로 많은 동시 요청을 처리할 수 있습니다. 그러나 성능이 낮은 머신의 GitLab Self-Managed 인스턴스는 비슷한 성능을 제공하지 않을 수 있습니다. 자세한 내용은 참조 아키텍처를 참조하십시오.
