기능을 완성했습니다. pull request는 깨끗합니다. QA는 좋다고 말합니다. 그리고 모든 사용자에게 동시에 배포하고 싶지 않습니다.
그런 느낌은 일반 배포에서 벗어난 React 앱이 성장했을 때 일반적으로 나타납니다. 제품이 실제 사용자에게 출시되면, 릴리즈는 기술적 이벤트에서 위험 결정으로 변합니다. 새로운 검색 UI가 깨지면, 체크아웃 버전이 사용자가 혼란스럽게 만든다면, 또는 code이 빌드가 빠르게 취소되지 않는다면, 더 많은 기능이 필요합니다. if (process.env.NODE_ENV) 그리고 희망.
그것은 어디에 리액트 기능 플래그 시작하는 곳입니다. 기능 플래그는 컴포넌트 내의 boolean 값이 아니라, 배포 제어层로 작동하여 code를 별도로 배포할 수 있게 해줍니다. 웹 앱에서 이는 더 안전한 롤아웃을 의미하며, Capacitor나 Electron과 같은 패키지 앱에서는 롤백 속도가 스토어 리뷰, 설치 지연, 느린 릴리스 주기에 의해 제한되기 때문에 더 중요합니다.
목차
- 모던 리액트 앱에서 기능 플래그의 중요성
- 리액트 앱에서 기능 플래그를 설계하는 방법
- 롤아웃 및 롤백 전략 구현
- 플래그의 관찰성 테스트 및 플래그 부채 관리
- 플래그를 안전하게 보호하고 CI/CD 자동화
- 웹 이외의 기능 플래그: Capacitor 및 모바일 앱을 위한
모던 React 앱에서 기능 플래그가 필수적이란 이유
금요일 오후 릴리스. 새로운 청구 요약 UI는 이미 배포되었고, 지원 팀은 런칭 체크리스트를 열었으며, 한 기업 고객은 월요일까지 이전 흐름을 사용해야 합니다. 웹 앱에서 이미 긴장감이 있습니다. 데스크톱 설치 프로그램 또는 모바일 스토어를 통해 배포된 React 앱의 경우, 롤백이 몇 분에서 몇 일까지 걸릴 수 있기 때문에 상황이 더 나빠집니다.
Feature flags give React teams control over that moment. They let you ship the code, keep it dormant, and decide later which users should see it. That changes release work from an all-or-nothing event into a controlled operation.
배포와 릴리스는 다른 작업입니다
배포는 “code이 프로덕션에 있는지?”라는 질문에 답합니다. 릴리스는 “현재 이 동작을 실행할 수 있는 사용자가 누구인지?”라는 질문에 답합니다.
실제 트래픽, 여러 환경, 수익, 권한 또는 네비게이션과 관련된 기능이 있는 React 앱에서 그 차이점은 중요합니다. 팀은 초기에 병합할 수 있고, 내부 코호트에서 프로덕션에서 테스트하고, 기능이 모든 사용자에게 준비되지 않은 상태에서 이미 사용자에게 배포된 바이너리를 제어할 수 있습니다. 더 느린 릴리스 플랫폼인 Capacitor 앱, Electron 앱 및 스토어 검토된 모바일 빌드의 경우, 그 제어는 사용자가 모든 기능이 준비되지 않은 상태에서 이미 바이너리를 사용하고 있는 경우에 thậm chí 더 가치가 있습니다.
기호는 세 가지 상황에서 도움이 됩니다.
- 제어된 롤아웃: 작은 그룹에 새로운 경로를 노출합니다.
- 실험: 변형을 비교할 수 있습니다. 별도의 배포를 유지할 필요가 없습니다.
- 빠른 종료: 위험한 기능을 비활성화할 때 새로운 빌드를 기다리지 않습니다.
생산 문제를 되돌리기 위한 비용이 높다면, 그 code을 기호 뒤에 배포하세요.
기호에 새로운 팀이 접근하면 종종 UI 조건부에 멈춥니다. flag ? <NewUI /> : <OldUI /> 그것은 눈에 보이는 부분이지만, 그것은 흥미로운 부분이 아닙니다. 그 핵심 가치는 운영입니다. 원격 구성, 결정론적 목표 설정 및 기능을 빠르게 비활성화할 수 있는 능력은 기호가 프로덕션에서 유용하다는 것을 만듭니다. 만약 React 앱이도 앱 전체의 런타임 설정이 필요하다면, __CAPGO_KEEP_0__ 앱용 원격 구성 플러그인 remote config plugin for Capacitor apps __CAPGO_KEEP_0__
신뢰할 수 없으면 유용하지 않다.
나는 성장하는 frontend 코드베이스에서 동일한 실패 패턴을 보았다. 팀은 플래그를 빠르게 추가하고, 환경 간 이름이 드리프트 되며, 기본값이 설정 오류를 숨기고, 누구도 'on'이 전역적으로 on인지, 직원에게 on인지, 스테이징에서만 on인지 알 수 없게 된다. 그 시점에서 플래그 시스템은 위험을 줄이는 대신 위험을 증가시킨다.
타입 안전성이 도움이 되지만, 문제의 전부를 해결하지는 않는다. 팀은 여전히 명확한 레지스트리, 소유권, 앱 내에서 플래그를 평가하는 일관된 방법이 필요하다. 그렇지 않으면, React 컴포넌트는 로캘 상태에 대한 지역적인 가정으로 끝나고, 출시 또는 부분 롤백 중에 그 가정들이 깨지게 된다.
차이점은 쉽게 구분할 수 있다.
| 사용 사례 | Weak 버전 | Strong 버전 |
|---|---|---|
| UI 토글 | 컴포넌트 상태의 지역 boolean | 소유권과 롤아웃 규칙이 있는 Remote 플래그 |
| 릴리스 안전 | 수동 배포 롤백 | 원격 구성으로 즉시 비활성화 |
| 실험 | 임시 branch 비교 | 안정된 집단 assign 및 측정 가능한 노출 |
중요한 마음의 전환은 간단합니다. React 기능 플래그는 JSX에만 국한된 것이 아니라 릴리스 프로세스의 일부입니다. 그들을 그들대로 다루세요, 특히 배포 속도가 느린 앱에서, 그들은 프로덕션에서 혼란스럽게 되면 폭파 반경을 줄이는 유일한 도구가 됩니다.
React 앱의 기능 플래그 아키텍처
아키텍처 결정이 첫 번째 플래그보다 더 중요합니다. 랜덤 컴포넌트에 플래그를 직접 연결하면 중복된 논리, 로딩 깜빡임, 코드베이스에서 누구도 신뢰할 수 있는 소스 코드를 찾을 수 없는 코드베이스가 됩니다.
런타임 제공자 사용, 분산 조건문 사용하지 않기
React 앱의 경우 신뢰할 수 있는 방법은 플래그를 런타임 데이터로 다루는 것입니다. React 플래그 지침은 세 가지 것을 권장합니다: 서버나 로컬 SDK 캐시에 플래그를 평가하십시오, 집단 assign을 결정론적으로 저장하십시오, 그리고 하이더레이션 또는 사용자들이 잘못된 기본값을 먼저 보지 않도록 UI 최종 상태를 렌더링하거나 항이 깜빡임 보호를 사용하십시오.React 플래그 방법론).
code 위치를 변경합니다. 플래그 로딩을 앱 루트 근처에 두십시오. 소비를 단순화하십시오. 리프 컴포넌트 내부에서 플래그를 가져오지 마십시오.
실용적인 형태는 다음과 같습니다:
- 메인 TREE가 렌더링되기 전에 플래그를 로드하거나 수분합니다.
- 제공자 через로 노출합니다.
- 하나의 훅 또는 하나의 wrapper 패턴을 통해 읽습니다.
- 표현적 컴포넌트 내부의 평가 로직을 유지하지 마십시오.
앱 전반적인 설정 및 플래그를 위한 원격 구성层가 필요하다면, 앱을 위한 하이브리드 React 앱에서 자연스럽게 이 패턴과 함께 사용할 수 있는 도구인 Capacitor 원격 구성 플러그인 이 패턴 1: React Context와 커스텀 훅
이것은 일반적으로 추천하는 기본 패턴입니다. 명시적이고 테스트할 수 있으며, 후에 벤더를 변경할 때 쉽게 마이그레이션할 수 있습니다.
If you need a remote config layer for app-wide settings as well as flags, a tool like
import React, { createContext, useContext, useMemo } from 'react';
type FlagValue = boolean | 'control' | 'variant-a' | 'variant-b';
type Flags = {
newCheckout: boolean;
checkoutExperiment: FlagValue;
deleteTaskEnabled: boolean;
};
const defaultFlags: Flags = {
newCheckout: false,
checkoutExperiment: 'control',
deleteTaskEnabled: false,
};
const FeatureFlagContext = createContext<Flags>(defaultFlags);
export function FeatureFlagProvider({
flags,
children,
}: {
flags: Flags;
children: React.ReactNode;
}) {
const value = useMemo(() => flags, [flags]);
return (
<FeatureFlagContext.Provider value={value}>
{children}
</FeatureFlagContext.Provider>
);
}
export function useFeatureFlag<K extends keyof Flags>(key: K): Flags[K] {
return useContext(FeatureFlagContext)[key];
}__CAPGO_KEEP_0__
function DeleteTaskButton() {
const enabled = useFeatureFlag('deleteTaskEnabled');
if (!enabled) return null;
return <button>Delete task</button>;
}사용은 지루하지만, 그것이 정확히 원하는 것입니다:
이 패턴은 잘 작동하는 이유는 컴포넌트가 최종 결과만을 요구하기 때문입니다. 그들은 결과가 어떻게 계산되었는지 신경 쓰지 않습니다.
두 번째 패턴: 고차 컴포넌트 고차 컴포넌트 고차 컴포넌트는 전역화된 화면, 경로 요소, 또는 레거시 클래스 컴포넌트를 제어하고 싶을 때 유용합니다. 모든 컴포넌트에 hook 호출을 추가하지 않고도.
import React from 'react';
import { useFeatureFlag } from './FeatureFlagProvider';
export function withFeatureFlag<P>(
flagKey: 'newCheckout' | 'deleteTaskEnabled',
Fallback?: React.ComponentType<P>
) {
return function wrap(Component: React.ComponentType<P>) {
return function FeatureFlaggedComponent(props: P) {
const enabled = useFeatureFlag(flagKey);
if (!enabled) {
return Fallback ? <Fallback {...props} /> : null;
}
return <Component {...props} />;
};
};
}사용법:
const CheckoutPage = () => <div>New checkout</div>;
const LegacyCheckoutPage = () => <div>Legacy checkout</div>;
export default withFeatureFlag('newCheckout', LegacyCheckoutPage)(CheckoutPage);단점은 간접성입니다. Hooks는 현대 React에서 추적하기 더 쉽지만, HOCs는 개발자 도구에서 컴포넌트树를 더 많은 잡음으로 만들 수 있습니다. 여전히, 경로 수준의 게이트는 깨끗합니다.
컴포넌트가 배포 정책을 결정하지 말라. 컴포넌트는 플래그 결과를 소비해야 하며, 버킷링, 사용자 대상 설정, 또는 캐시 리프레시 규칙을 implement하지 말라.
React 기능 플래그 패턴 비교
| 기준 | 컨텍스트 + Hook | 상위 주문 컴포넌트 (HOC) |
|---|---|---|
| 최적의 사용 사례 | 컴포넌트 수준의 결정과 변형 | 전체 페이지, 경로 또는 레거시 컴포넌트 wrapping |
| flexibility | 높음 | 중간 |
| 개발자 경험 | 최신 함수 컴포넌트에서 강력함 | HOOKS가 불편할 때 유용함 |
| 배포 명확성 | 명확한 import 및 직접 읽기 | tree의 추상화 |
| 테스트 | 제공자로 mock하기 쉽습니다 | wrap된 통합 케이스에 쉽습니다 |
| 장기적인 유지보수성 | 일반적으로 좋습니다 | 적절히 사용할 때는 괜찮습니다 |
리액트 기능 플래그를 처음 implement하는 경우에는 컨텍스트 + 훅HOC를 추가할 때는 wrapper-style gating에 특정한 필요성이 있을 때만
롤아웃 및 롤백 전략 implement
기능이 출시 후 문제가 발생한 날에 rollout plan이 가장 중요합니다. UI에서는 새로운 버튼이나 화면만 보여주지만, 결정해야 하는 것은 누가 먼저 보게 할 것인지, 노출 속도는 얼마나 빠르게 증가할 것인지, 그리고 재배포를 기다리지 않고 즉시 중단할 수 있는 방법입니다. 이는 리액트 앱이 모바일 또는 데스크톱 배포에 포함된 경우, 롤백은 remote config에 의존할 수 있습니다. 앱 스토어 리뷰 또는 데스크톱 배포는 시간이 걸리기 때문입니다.
퍼센트 롤아웃은 고정 assignment이 필요합니다.
퍼센트 롤아웃은 assignment이 안정적일 때만 작동합니다. 만약 동일한 사용자가 새로운 체크아웃을 방문하고 다음 방문에서는 이전 체크아웃을 방문한다면, 지원 팀은 문제를 reproduce할 수 없고, 분석은 noisy해지고, 사용자는 신뢰를 잃습니다.
해결책은 간단합니다. 사용자를 stable identifier에 대한 deterministic hash에 flag key를 추가하여 bucket합니다. 일반적으로 User ID가 올바른 입력입니다. 익명 세션은 installation ID 또는 device ID를 사용할 수 있습니다. 만약 하나를 가지고 있다면. Math.random() 브라우저 내에서 사용자 재assignment이 불안정하기 때문에 브라우저 내에서 사용하는 것은 올바른 도구가 아닙니다.
실제 롤아웃 경로는 다음과 같습니다.
- 내부 사용자와 QA부터 시작합니다.
- 작은 코호트에 릴리스합니다.
- 오류율, 변환 영향, 지원 티켓을 확인한 후 의도적으로 단계별로 확장합니다.
- 플래그의 전체 생애주기 동안 assignment을 고정합니다.
마지막 점은 쉽게 과소평가할 수 있습니다. sticky cohorts는 실험 외에도 incident response를 빠르게 하기 때문에 엔지니어는 즉시 기본적인 질문에 답할 수 있습니다: 노출된 사용자는 누구였습니까?
만약 실험이라면, 실험 크기를 미리 결정하세요. Optimizely에서 제공하는 sample size calculator는 traffic volume, baseline conversion, minimum detectable effect가 variant당 필요한 사용자 수를 결정하는지 보여줍니다.Optimizely 샘플 크기 계산기그런 경우, 팀은 노이즈를 신호로 읽고 특정 기능을 너무 일찍 홍보할 수 있습니다.
브라우저 외부의 단계적 업데이트에 대한 유용한 참고 자료는 Capacitor 실시간 업데이트에 대한 단계적 롤아웃패키징된 셸 내에서 React 앱이 실행되는 경우에도 동일한 릴리스 규칙이 적용됩니다. 바이너리 롤백이 느리기 때문입니다.
대상 및 링 기반 릴리스는 폭파 반경을 줄입니다.
일부 기능은 랜덤 퍼센티지로 시작하지 않아야 합니다. 청구 흐름, 권한 요청, 데이터 마이그레이션 및 사용자를 차단할 수 있는 기능은 모두 대상 릴리스로 먼저 시작해야 합니다.
대상이 정의된 첫 번째 청중이 알려진 특성에 의해 정의될 때 타겟팅이 잘 작동합니다.
- 내부 직원은 내부 테스트를 위해
- ROUGH EDGE에 동의한 베타 테스터
- 특정 계정 계층
- 법적 또는 언어 요구 사항이 다른 지역
- __CAPGO_KEEP_0__
Ring-based release 모델은 더 많은 운영성을 제공합니다. Ring 0은 직원입니다. Ring 1은 신뢰할 수 있는 외부 테스터입니다. 나중에 링은 자신감이 향상될 때 노출을 확대합니다. 이 구조는 팀이 모든 사용자를 하나의 풀로 다루는 일반적인 오류를 피할 수 있도록 도와줍니다. 사용자가 분명히 불균형한 위험을 가지고 있을 때입니다.
이 릴리스 모델과 잘 어울리는 내장_walkthrough입니다.
위험한 기능이 있는 경우 빠른 비상 경로가 필요합니다. 실제로 일반적으로 상위 수준의 운영 플래그가 전체 기능 흐름을 비활성화하는 것을 의미합니다. 그만큼이 하나의 진입점을 숨기기만 하는 표시 플래그가 아니라 배경 요청, 효과 또는 탐색 경로가 여전히 실행되는 것입니다.
출시 전에 kill switch를 설계하십시오.
앱 시작 시에 그것을 평가하십시오.
- 최근에 안전한 값을 캐시하십시오.
- 플래그 서비스가 사용할 수 없을 때는 안전한 기본값을 선택하십시오.
- 기능을 비활성화하면 사이드 이펙트가 중단되도록 하십시오. 렌더링만 중단되는 것이 아닙니다.
- 사고 시에 그것을 누르려는 사람을 문서화하십시오.
- 웹 전용 앱의 경우 릴리스 위험을 줄입니다. 모바일 및 데스크톱 React 앱의 경우, 그것은 미니언 인스턴트와 사용자가 고정된 빌드를 받을 때까지 기다리는 차이일 수 있습니다. __CAPGO_KEEP_0__가 이미 배포된 경우, remote 플래그는 롤백 전략이 아닌 릴리스 전략이 됩니다.
code
관찰성 및 플래그 부채 관리
기능 플래그의 쉬운 부분은 하나를 추가하는 것입니다. 비싼 부분은 나중에 시작되는데, 그때는 많은 플래그가 있고 nobody가 아직 중요하다고 기억하지 못하는 플래그가 있습니다.
각 플래그는 신뢰해야 하는 상태의 수를 여러 번으로 증가시킵니다.
마틴 파울러의 경고는 여전히 유효합니다: 기능 플래그가 존재하면 팀은 'On'과 'Off' 상태를 모두 검증해야 합니다. On and Off 상태 combination은 combinatorially 증가하여, 이는 회귀 위험을 높입니다 (마틴 파울러에 대한 기능 토글).
그것은 React 앱에 직접적인 영향을 미칩니다:
- 조건부 렌더링 경로가 빠르게 퍼지기 시작합니다: __CAPGO_KEEP_0__
- 다중 branch가 여러 개 존재할 수 있습니다. 사용자가 이를 인지하기 전에. hydration mismatch가 발생하기 쉬워집니다.
- 클라이언트와 서버가 평가 시간이 잘못되면 의견이 다를 수 있습니다. happy-path render만으로는 충분하지 않습니다. 반대 flag 상태가 테스트되지 않은 경우.
실용적인 테스트 스택은 다음과 같습니다.
- 평가 로직을 단위 테스트합니다.
- key flagged branch를 컴포넌트 테스트합니다.
- 위험한 경로만을 종단 간으로 테스트합니다.
- 기본값 fallback을 명시적으로 검증합니다.
모든 combination을 테스트하는 것은 일반적으로 무거워집니다. 사용자가 피해를 볼 수 있는 상태나 레이아웃이 깨질 수 있는 상태만 테스트합니다.
flag debt는 실제로 존재하며 비용이 쌓이게 됩니다.
code이 된 旧 플래그는 썩는 과정의 일부가 됩니다. 그들은 조건문, 주석, 대시보드, 그리고 실행 계획서에 남아 있습니다. 그리고 alguien이 몇 달 후에 “임시” branch를 편집하기 때문에 nobody이 제거하지 않았습니다.
실제로 작동하는 청소 규칙은 간단합니다:
| 문제 | 무엇을 해야 하나요 |
|---|---|
| 관리자가 없어요 | 플래그가 생성될 때 팀이나 사람을 assign하세요 |
| 결과가 없어요 | 플래그가 제거되거나 config로 변환되거나 남아 있는지 결정하세요 |
| 플래그가 너무 많은 제어권을 가지고 있어요 | 작은 플래그로 나누세요 |
| 핵심 로직이 플래그 뒤에 숨겨져 있어요 | 비즈니스 로직을 렌더링 조건문에서 빼세요 |
정리 규칙: 일단旗를 설정하면, 모든旗는 첫날부터 주인, 목적, 제거 계획이 있어야 합니다.
이것도 팀이 '신뢰' 문제로 당하는 곳입니다.旗의 이름은 존재하지만, 기본값이 잘못되었습니다. 대시보드 항목이 변경되었습니다. 그러나 앱 타입은 변경되지 않았습니다. code 경로는 죽었지만 여전히 접근할 수 있습니다. 따라서, 큰 시스템에서 초기 구현이 간단하게 보였더라도, 타입 생성과 레지스트리 검증이 중요합니다.
관측 가능성은旗가 사용자에게 도움이 되었는지, 단순히 존재했는지 알려줍니다.
배포가 완료된 것은旗가 완전한 노출을 달성했을 때가 아닙니다. 완료된 것은 팀이 무슨 일이 일어났는지 알았을 때입니다.
다음 질문들을 추적하세요:
- 노출: 어떤 사용자가 어떤 버전을 보았을까요?
- 에러: 기호화된 경로가 클라이언트 측 실패를 더 많이 트리거했습니까?
- 수용: 사용자가 노출된 기능을 사용했습니까?
- 롤백 신호: 어떤 기준을 넘어서면 끄겠습니까?
플래그 플랫폼이 이 질문에 답하지 못하면, 릴리즈 리뷰 시에도 여전히 추측하게 될 것입니다.
CI/CD를 이용한 플래그 보안 및 자동화
잘못된 배포는 뚜렷합니다. 잘못된 플래그 변경은 더 조용하고, 때로는 더 위험할 수 있습니다. 왜냐하면 그것은 code 경로를 변경하는 생산 동작을 거치지 않고도 리뷰 경로를 거치지 않기 때문입니다.
플래그 변경을 프로덕션 변경과 같이 다루세요.
플래그는 릴리즈 제어입니다. 만약 팀이 프로덕션에서 플래그를 켜거나 끌 수 있다면, 그 팀은 사용자가 받는 것을, code 경로가 실행되는 것을, 그리고 때로는 어떤 통합이 실행되는지를 변경할 수 있습니다. 이것은 배포 접근 권한과 같은 제한을 받을 자격이 있습니다.
최소한의 제어는 다음과 같습니다:
- 역할 기반 접근 권한: 프로덕션 플래그 변경을 제한하고, 읽기 접근 권한과 수정 접근 권한을 분리하세요.
- 감사 로그: 변경 내역을 명확하게 기록하여, 누가 플래그를 변경했는지, 언제 변경했는지, 그리고 어떤 환경을 조작했는지 기록하세요.
- 환경 분리: 테스트 변경이 실시간 트래픽으로 흘러들지 않도록, 스테이징, 미리보기 및 프로덕션 플래그가 구별되어야 합니다.
- _sensitive한_결정에 대한 서버측_체크: 클라이언트 플래그는 UI를 숨길 수 있지만, 계정 승인, 특권, 또는 인증을 결정하는 데는 사용하지 shouldn't.
플래그 대시보드를 공유 스프레드시트처럼 다루지 마세요. 제품은 고객에게 특정 기능을 활성화합니다. 지원 팀은 불만을 해결하기 위해 기능을 비활성화합니다. 엔지니어는 배포가 없다고 가정하여 nobody가 기능을 조작하지 않았을 것으로 생각합니다. 그러나 이러한 설정은 사고를 설명할 때까지 작동합니다.
배포된 앱은 위험을 높입니다. 웹 앱의 code修正은 빠르게 배포될 수 있지만, 데스크톱 앱의 Capacitor or 데스크톱 앱의 code은 이미 기기에 설치되어 있고, remote 플래그가 기능을 노출시키기만 하면 문제가 발생할 수 있습니다. code React mobile apps with Capacitor pipeline 내부에 플래그 연산을 포함하세요.
플래그가 배포 프로세스 외부에 존재할 때 신뢰성이 떨어집니다. safer 패턴은 플래그를 배포 프로세스와 함께 관리하는 것입니다.
일반적으로 이는 다음과 같은 것을 의미합니다:
__CAPGO_KEEP_0__
- 기능 code을 생성하거나 업데이트할 때 동일한 PR에서 플래그를 생성하거나 업데이트하세요.
- CI 동안远程 레지스트리에 정의된 플래그의 타입을 검증하세요.
- 환경에 따라 기본값을 의도적으로 설정하세요.
- 필요한 플래그가 누락되거나 잘못 구성되어 있다면 릴리즈를 차단하세요.
- 플래그가 만료 날짜 또는 롤아웃 종료 상태를 가지고 있다면 클린업 작업을 스케줄링하세요.
제품 오류가 플래그로 인해 발생할 수 있다면, CI가 릴리즈 전에 설정을 검사할 수 있어야 합니다. 이는 기본값이 누락된 경우, 키 이름이 변경된 경우, 환경 매핑이陈舊한 경우, 그리고 code에만 존재하는 플래그가 제어 평면에 존재하지 않는 경우를 포함합니다.
pipeline 구조에 대한 시작점이 필요하다면 Git Action CI/CD 워크플로우 빌드 체크, 배포 게이트, 플래그 검증을 위한 자동화 단계를 확장할 수 있는 빌드 체크, 배포 게이트, 자동화 단계의 견고한 참조입니다.
비밀을 숨기고 SDK 선택을 단순하게 유지하세요.
프론트엔드 팀은 플래그 보안을 과도하게 복잡하게 만들고 명백한 부분을 놓치곤 합니다. 브라우저 사용을 위해 설계된 일반적인 SDK 키는 일반적으로 클라이언트 측 평가에 문제가 없습니다. 그러나 관리자 토큰, 쓰기 자격 증명, 환경 관리 키는 CI 또는 백엔드 서비스에만 속해야 합니다.
실용적인 분리는 간단합니다. 프레젠테이션 변경이나 낮은 위험의 실험에 대해 클라이언트 측 평가를 사용하고, 가격, 권한,敏感한 흐름의 죽은 스위치, 또는 당신이 로컬 자바스크립트에 신뢰하지 않는 모든 것을 서버 측 평가를 사용하세요.
느린 릴리스 환경에서 경계가 더 중요합니다. 웹 팀은 빠른 배포로 회복할 수 있습니다. 모바일 및 데스크톱 팀은 종종 플래그 시스템이 회복 메커니즘으로 사용되어야 합니다. 잘못된 사람들만이 프로덕션 플래그를 편집할 수 있고, CI가 플래그 계약을 검증하지 않는다면 롤백은 빠르게 복잡해집니다.
웹 Capacitor 및 모바일 앱을 위한 Web Feature Flags
대부분의 리액트 플래그에 대한 기사들은 즉시 다시 배포할 수 있는 웹 앱을 가정합니다. 그런 가정은 리액트 code이 다른 code 내부에 존재하는 순간에 깨집니다. Capacitor, Electron, 또는 다른 번들 런타임.
번들 앱은 릴리스 수학을 변경합니다.
하이브리드 앱에서, 개발자가 즉시 업데이트하지 않는 사용자에게 배포하는 JavaScript, CSS, 자산 및 설정을 포함하는 번들이 자주 배포됩니다. 기능이 사용자에게 사용하도록 허용하기 전에 이미 기기에 이미 설치되어 있습니다. 그게 플래그의 역할을 완전히 바꾸는 것입니다.
하이브리드 릴리스 전략에 대한 최근 토론에서, existing 리액트 플래그 콘텐츠가 Capacitor 또는 Electron 앱의 릴리스-리스크 모델을 충분히 다루지 않는다는 점을 지적했습니다. 그 팀에게는 플래그, 대상 채널 및 롤백 보호를 결합하는 릴리스 오케스트레이션 레이어가 필요합니다. 단순한 on/off switch 대신, 특히 스토어 리뷰 지연을 피해야 할 때.하이브리드 앱 릴리스-리스크 토론).
그것이 정확합니다. 번들 앱에서 플래그는 조건부 렌더링에 더 이상 관련이 없으며, 이미 배포된 기능을 원격으로 활성화하는 것입니다. 그것이 정확합니다. 번들 앱에서 플래그는 조건부 렌더링에 더 이상 관련이 없으며, 이미 배포된 기능을 원격으로 활성화하는 것입니다..
모바일 또는 데스크톱 React 앱에서 플래그는 UI 존재 여부보다 릴리즈 타이밍을 더 많이 제어합니다.
This is also why channel-based distribution matters. If you’re building hybrid apps and need the app shell plus web code release model to make sense together, React 모바일 앱을 만들 때 Capacitor __CAPGO_KEEP_0__
모바일 및 데스크톱 팀에서 플래그만으로는 모든 릴리즈 문제를 해결할 수 없습니다. 플래그는 __CAPGO_KEEP_0__ 경로를 숨기거나 활성화할 수 있지만 이미 배포된 번들의 버그를 고치지 못합니다.
For mobile and desktop teams, flags alone won’t solve every release problem. They can hide or enable code paths, but they can’t replace shipping fixed assets or logic when the bug is already in the bundle.
__CAPGO_KEEP_0__ 업데이트를 풀 스토어 사이클 밖에서 배포하고 플랫폼이 허용할 때
- deliver code updates outside full store cycles when your platform allows it,
- 플래그를 사용하여 활성화, 롤백 및 스테이지드 노출을 제어하세요.
- 라이브 업데이트와 플래그를 함께 사용하면 하이브리드 팀은 웹 스타일의 릴리즈 제어를 가질 수 있습니다. 이것은 discipline이 필요하지 않다는 것을 의미하지 않습니다. 단지 여러분이 잘못된 것을 고치기 위해 여러 개의 레버를 가질 뿐입니다.
여러분의 팀이 __CAPGO_KEEP_0__ 또는 Electron 앱을 배포하고 릴리즈 제어层가 필요하다면
If your team ships Capacitor or Electron apps and needs that release-control layer, Capgo signed web bundles을 제공하는 또 다른 옵션입니다. signed web bundles을 특정 채널로 전달하고 롤백 보호 및 관찰 가능성을 지원하며, 기능 플래그가 라이브 업데이트와 함께 작동해야 하는 하이브리드 앱 워크플로에 적합합니다.
React Feature Flags: A Complete Implementation Guide
이 가이드를 사용하고 있다면 React Feature Flags: A Complete Implementation Guide 채널 라우팅과 스테이지드 롤아웃을 계획하기 위해 Channels Channels Channels Channels Channels Channels 베타 테스트 솔루션 베타 테스트 솔루션의 제품 워크플로우에 대해, 그리고 버전 목표 솔루션 버전 목표 솔루션의 제품 워크플로우에 대해, 그리고
