React 기능 플래그: 완전한 구현 안내서

제품을 완성했으며 pull request가 깨끗합니다. QA 팀은 기능이 좋다고 말합니다. 그러나 모든 사용자에게 동시에 배포하고 싶지 않습니다.

이러한 느낌은 일반적인 배포가 기술적인 일만 아니라 실제 사용자가 있는 제품이 커졌을 때 발생하는 첫 번째 신호입니다. 새로운 검색 UI가 깨지거나, 체크아웃 버전이 사용자가 혼란스럽게 만든다면, 또는 모바일 빌드가 배포되면 code이 빨리 되돌릴 수 없다면, 더 많은 것을 필요로합니다. if (process.env.NODE_ENV) 그리고 희망만으로는 충분하지 않습니다.

그것은 여기서 시작됩니다. 리액트 기능 플래그 배포 제어 레이어로 시작하여, 배포와 노출을 분리하여 code을 별도로 배포할 수 있습니다. 웹 앱에서 이는 더 안전한 롤아웃을 의미하며, Capacitor 또는 Electron과 같은 패키지 앱에서는 롤백 속도가 스토어 리뷰, 설치 지연, 느린 릴리스 사이클에 의해 제한되기 때문에 더 중요합니다.

모던 리액트 앱에서 기능 플래그의 중요성
- 배포와 릴리스는 다른 작업입니다
- 기호가 믿을 수 없을 때 nobody는 도움이 더 이상되지 않습니다
React 앱에서 기능 플래그를 설계하는 방법
롤아웃 및 롤백 전략 구현
관찰성 테스트 및 플래그 부채 관리
CI/CD를 자동화하여 플래그를 보호하는 방법
Capacitor 및 모바일 앱을 위한 웹 기능 플래그
- 배포 수식이 변경되었습니다
- 업데이트 전달과 함께 플래그를 pair하면 가장 잘 작동합니다

모던 리액트 앱에서 기능 플래그가 필수적입니다

금요일 오후, 새로운 청구 요약 UI가 이미 배포되었고, 지원 팀은 런칭 체크리스트를 열었으며, 월요일까지는 하나의 기업 고객이 여전히 이전 흐름을 사용해야 합니다. 웹 앱에서 이미 긴장감이 있습니다. 데스크톱 설치 프로그램 또는 모바일 스토어를 통해 배포되는 패키지된 리액트 앱에서 상황은 더 나빠집니다. 롤백이 몇 분에서 몇 시간 또는 며칠까지 걸릴 수 있기 때문입니다.

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.

기능 플래그가 현대 React 앱에 필수적인 이유를 설명하는 인포그래픽입니다.

배포와 릴리즈는 다른 작업입니다.

배포는 'code이 프로덕션에 있는가?'라는 질문에 답합니다. 릴리즈는 '현재 이 동작을 실행할 수 있는 사용자가 누구인가?'라는 질문에 답합니다.

React 앱이 실제 트래픽을 받고, 여러 환경과 기능이 수익, 권한, 또는 네비게이션과 관련된 경우, 이 구분은 중요합니다. 팀은 조인할 수 있게 되고, 내부 그룹과 함께 프로덕션에서 테스트할 수 있고, 기능이 모든 사용자에게 준비되지 않은 상태에서만 접근할 수 있습니다. 느린 릴리즈 플랫폼인 Capacitor 앱, Electron 앱, 또는 스토어 검토된 모바일 빌드의 경우, 이러한 통제권은 더 가치가 있습니다. 왜냐하면 바이너리가 이미 사용자들의 손에 있는 상태에서 기능이 모든 사용자에게 준비되지 않은 상태일 수 있기 때문입니다.

기능 플래그는 다음과 같은 세 가지 상황에서 도움이 됩니다.

제어된 롤아웃: 작은 그룹에게 새로운 경로를 노출합니다.
실험: 변형을 비교할 수 있습니다. 별도의 배포를 유지할 필요가 없습니다.
빠른 종료: 위험한 기능을 비활성화할 수 있습니다. 새로운 빌드를 기다리지 않아도 됩니다.

이러한 경우 단순한 규칙이 잘 작동합니다. 만약 프로덕션 문제를 되돌리기 위한 비용이 비싸다면, 그 code을 플래그 뒤로 보내세요.

플래그에 익숙하지 않은 팀은 UI 조건부에 멈춥니다. flag ? <NewUI /> : <OldUI /> UI는 보이는 부분이지만, 흥미로운 부분은 아닙니다. 플래그의 핵심 가치는 운영입니다. 원격 구성, 결정론적 타겟팅, 그리고 특정 기능을 빠르게 끄는 능력은 프로덕션에서 플래그가 유용한 이유입니다. 만약 React 앱이도 앱 전체에서 런타임 설정이 필요하다면, __CAPGO_KEEP_0__ 앱에 대한 remote config 플러그인 remote config plugin for Capacitor apps 플래그가 유용하지 않은 상황은 팀이 플래그를 신뢰하지 않는 경우입니다.

성장하는 프론트엔드 코드베이스에서 동일한 실패 패턴을 보입니다. 팀이 플래그를 빠르게 추가하고, 환경 간 이름이 드리프트하는 경우, 기본값이 숨겨진 구성 오류를 숨기고, 플래그 시스템이 위험을 증가시키는 대신 위험을 줄이는 데 도움이 되지 않습니다.

타입 안전성이 도움이 되지만, 문제의 전부를 해결하지는 않습니다. 팀이 명확한 레지스트리, 소유권, 그리고 앱 내 플래그를 평가하는 일관된 방법이 필요합니다. 그렇지 않으면, React 컴포넌트가 로캘 롤아웃 상태에 대한 지역적인 가정으로 끝나고, 런칭 또는 부분 롤백 중에 그 가정들이 깨집니다.

차이점은 쉽게 식별할 수 있습니다.

사용 사례

약한 버전	강한 버전	Use case
UI 토글	컴포넌트 상태 내의 지역 불리언	소유권 및 롤아웃 규칙이 있는 원격 플래그
릴리즈 안전	수동 배포 롤백	원격 구성으로 인한 즉시 비활성화
실험	어드 호크 브랜치 비교	안정된 계층 assignments 및 측정 가능한 노출

중요한 마음의 전환은 간단합니다. React 기능 플래그는 릴리즈 프로세스에 속합니다. JSX만 아니라, 특히 배포가 느린 앱에서, 새로운 빌드를 배포하는 것이 느려지면, 프로덕션에서 혼란이 생길 때 blast radius를 줄이는 유일한 도구가 됩니다.

React 앱 내의 기능 플래그 아키텍처

아키텍처 결정이 첫 번째 플래그보다 더 중요합니다. 만약 플래그를 임의의 컴포넌트에 직접 연결한다면, 중복된 로직, 로딩 깜빡임, 그리고 누구도 소스 코드의 진실을 믿을 수 없는 코드베이스가 생길 것입니다.

__CAPGO_KEEP_0__를 사용하는 런타임 제공자 대신에 산발적인 조건문 사용하지 마세요.

리액트 앱의 경우, 신뢰할 수 있는 방법은 플래그를 __CAPGO_KEEP_0__ 데이터로 다루는 것입니다. 리액트 플래그 메서드론. Guidance for React flagging recommends three things: evaluate flags on the server or in a local SDK cache, persist cohort assignment deterministically, and render the final UI state before hydration or use anti-flicker protection so users don’t see the wrong default first (실용적인 형태는 다음과 같습니다.).

That changes where your code should live. Put flag loading near the app root. Make consumption simple. Avoid fetching flags inside leaf components.

제공자로 노출하세요.

하나의 훅 또는 wrapper 패턴을 통해 읽어보세요.
표현적인 컴포넌트 내부에서 평가 로직을 유지하지 마세요.
앱 전체 설정 및 플래그를 위한 원격 구성层가 필요하다면, 앱 전반적인 설정과 플래그를 위한 도구인
__CAPGO_KEEP_0__를 사용하는 런타임 제공자 대신에 산발적인 조건문 사용하지 마세요.

리액트 앱의 경우, 신뢰할 수 있는 방법은 플래그를 __CAPGO_KEEP_0__ 데이터로 다루는 것입니다. Capacitor remote config 플러그인 이 패턴은 하이브리드 React 앱에서 자연스럽게 어울립니다.

React Context와 커스텀 훅을 사용하는 패턴 1

일반적으로 추천하는 기본 패턴입니다. 명확하고 테스트할 수 있으며, 후에 벤더를 바꾸더라도 쉽게 마이그레이션할 수 있습니다.

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];
}

사용은 여전히 재미가 없지만, 그게 바로 원하는 것입니다.

function DeleteTaskButton() {
  const enabled = useFeatureFlag('deleteTaskEnabled');

  if (!enabled) return null;
  return <button>Delete task</button>;
}

이 패턴은 컴포넌트가 최종 결과만을 원하기 때문에 잘 작동합니다. 그 결과가 어떻게 계산되었는지에 관심이 없습니다.

커스텀 훅을 사용하지 않고도 전역 화면, 경로 요소, 또는 레거시 클래스 컴포넌트를 게이트링하고 싶을 때 유용합니다.

사용법: 이 패턴의 단점은 간접성입니다. Hooks는 현대 React에서 추적하기 더 쉽지만, HOC는 개발자 도구에서 컴포넌트 트리 구조를 더 복잡하게 만들 수 있습니다. 여전히 경로 수준의 게이트링에서는 깨끗합니다. A

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);

고차 컴포넌트는 전역 화면, 경로 요소, 또는 레거시 클래스 컴포넌트를 게이트링하고 싶을 때 유용합니다. 컴포넌트에 훅 호출을 추가하지 않아도 됩니다.

__CAPGO_KEEP_0__의 rollout 정책을 컴포넌트가 결정하지 않도록 하세요. 컴포넌트는 플래그 결과를 소비해야 하며, 버킷팅, 사용자 대상 설정, 캐시 리프레시 규칙을 implement하지 않아야 합니다.

__CAPGO_KEEP_0__ React Feature Flag Patterns Compared

기준	컨텍스트 + 훅	고차 컴포넌트 (HOC)
__CAPGO_KEEP_0__의最佳사용 사례	컴포넌트 수준의 결정과 변형	__CAPGO_KEEP_0__의 전체 페이지, 경로, 또는 레거시 컴포넌트 wrapping
__CAPGO_KEEP_0__	__CAPGO_KEEP_1__	__CAPGO_KEEP_2__
개발자 경험	현대 함수 컴포넌트에서 강력함	HOOKS가 불편할 때 유용함
Bundle 명확성	명확한 임포트 및 직접 읽기	tree에서 더 많은 추상화
테스트	provider를 통해 쉽게 모킹	wrapped 통합 케이스에 쉽게 적용
장기적인 유지보수 가능성	보통 더 좋음	sparingly 사용할 때 괜찮음

Capgo를 처음 사용하는 경우 React feature flags를 구현할 때 시작하세요. 컨텍스트 + 훅. Add an HOC만 사용할 때 wrapper-style gating이 필요한 경우에만.

롤아웃 및 롤백 전략 구현

기능이 출시 후 문제를 일으키는 날, 롤아웃 계획이 가장 중요합니다. UI에서 새로운 버튼이나 화면만 보여주지만, 결정해야 할 것은 누구에게 먼저 보여주고, 노출 속도는 얼마나 빠르게 증가시키고, 빨리 롤백할 수 있는지입니다. 특히 모바일이나 데스크톱 앱에서 shipped된 React 앱은, 롤백이 remote config에 의존하는 경우 앱 스토어 리뷰나 데스크톱 배포가 시간이 걸리기 때문에 더 중요합니다.

소프트웨어 기능 플래그의 롤아웃 및 롤백 전략을 내부에서 글로벌로 출시하는 다이아그램.

퍼센티지 롤아웃은 고정 assignment이 필요합니다.

퍼센티지 롤아웃은 assignment이 안정적일 때만 작동합니다. 사용자가 한 방문에서 새로운 체크아웃을 받고 다음 방문에서旧 체크아웃을 받는 경우, 지원 팀이 문제를 reproduce할 수 없고, 분석이 노이즈가 되며, 사용자가 신뢰를 잃습니다.

해결 방법은 간단합니다. 사용자를 stable identifier의 hash와 플래그 키에 따라 bucketize합니다. 일반적으로 사용자 ID가 적절한 입력입니다. 익명 세션은 설치 ID나 장치 ID를 사용할 수 있습니다. Math.random() 브라우저에서 사용하는 것은 사용자를 예측할 수 없게 재assign하는 tool입니다.

실용적인 롤아웃 경로는 다음과 같습니다.

내부 사용자와 QA부터 시작합니다.
작은 코호트에 출시합니다.
오류율, 변환 영향, 지원 티켓을 확인한 후 의도적으로 단계별로 확장합니다.
플래그의 전체 생애주기 동안 assignment을 고정 유지합니다.

마지막 점은 쉽게 과소평가할 수 있습니다. 스틱이 코호트는 실험만을 위한 것이 아닙니다. 인시던트 리스폰스 시간을 단축시켜 engineer가 즉시 기본적인 질문에 답할 수 있습니다: 노출된 사용자는 누구였습니까?

실험을 수행한다면, 배포하기 전에 크기를 조정하세요. Optimizely의 샘플 크기 계산기에서 트래픽 볼륨, 기본 변환률, 최소 감지 가능한 효과가 사용자당 변형 수를 어떻게 변경하는지 보여줍니다 (Optimizely 샘플 크기 계산기). 변환률이 높지 않으면 팀이 노이즈를 신호로 오해하고 기능을 너무 일찍 승인하는 경우가 많습니다.

브라우저 외부의 단계별 업데이트에 대한 유용한 참고 자료는 Capacitor live updates의 단계적 롤아웃입니다. 동일한 릴리즈 디스크립린은 패키지드 셸 내부에서 React 앱이 실행되는 경우 바이너리 롤백이 느릴 때도 적용됩니다.

대상과 반지형 릴리즈는 폭파 반경을 줄입니다.

일부 기능은 랜덤 퍼센티지로 시작하지 shouldn't. 계정 잠금이 가능한 빌링 흐름, 권한 요청, 데이터 마이그레이션 등은 대상 릴리즈로 먼저 시작해야 합니다.

대상이 정의된 알려진 특성에 따라 첫 번째 청중을 정의하면 targeting이 잘 작동합니다.

__CAPGO_KEEP_0__ 직원
__CAPGO_KEEP_0__에서 베타 테스터
__CAPGO_KEEP_0__ 계정
__CAPGO_KEEP_0__ 지역
__CAPGO_KEEP_0__ 장치

링 기반 릴리스는 더 많은 운영성을 제공합니다. 링 0은 직원입니다. 링 1은 신뢰할 수 있는 외부 테스터입니다. 나중에 링은 자신감이 향상될 때 노출을 확대합니다. 이 구조는 팀이 모든 사용자를 하나의 풀로 다루는 일반적인 오류를 피할 수 있도록 도와줍니다. 이는 명백히 불균형한 위험을 고려하지 않기 때문입니다.

이 릴리스 모델과 잘 어울리는 내장_walkthrough입니다.

킬 Switch는 기능을 안전하게 사용할 수 있는 장치입니다.

모든 위험한 기능에는 빠른 오프 패스를 설계해야 합니다. 일반적으로 이는 전체 기능 흐름을 비활성화하는 상위 수준의 운영 플래그를 의미합니다. 이는 하나의 진입점만 숨기기 위해 배경 요청, 효과, 또는 탐색 경로가 여전히 실행되는 표시 플래그만 있는 것이 아닙니다.

릴리스 전에 kill switch를 설계하십시오.

앱 시작 시에 그것을 평가하십시오.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__가 unavailable인 경우 기본적으로 안전한 값을 선택하세요.
기능을 비활성화하는 것이 렌더링을 멈추는 것만이 아닌, 부수적인 효과를 멈추는 것을 보장하세요.
사고 시 이 기능을 변경할 수 있는 사람을 문서화하세요.

웹 전용 앱의 경우, 릴리스 위험을 줄입니다. 모바일 및 데스크톱 React 앱의 경우, 이 기능이 미니언 사고와 사용자가 고정된 빌드를 받을 수 있도록 기다리는 것 사이의 차이를 만들 수 있습니다. code가 이미 배포된 경우, remote flags는 릴리스 전략뿐만 아니라 롤백 전략이 됩니다.

기능 플래그 관찰성 테스트 및 플래그 부채 관리

기능 플래그의 쉬운 부분은 하나를 추가하는 것입니다. 비싼 부분은 나중에 시작되는데, 그때는 이미 많은 플래그가 존재하고 어떤 플래그가 여전히 중요하다는 것을 기억하지 못하는 경우입니다.

서버 룸의 현대적인 모습을 담은 사진입니다. 서버 랙과 네트워크 케이블이 조직적으로 배열되어 있습니다.

각 플래그는 신뢰할 수 있는 상태의 수를 증가시킵니다.

Martin Fowler의 경고는 여전히 유효합니다: 기능 플래그가 존재하면 팀은 On and Off 상태와 여러旗를 사용하면 가능한 상태 combination이 combinatorially 증가하여 regression risk를 높힌다 (Martin Fowler on feature toggles).

Capgo 앱에 대한 직접적인 결과는 다음과 같습니다:

조건부 렌더링 경로가 빠르게 퍼지기 때문에: 한 페이지에 여러 branch가 존재할 수 있다. 사용자가 이를 인지하기 전에.
hydration mismatch가 더 쉽게 발생할 수 있다. 클라이언트와 서버가 평가 시간이 잘못되면 의견이 다를 수 있다.
snapshot test가 단독으로는 더 이상 유용하지 않다. happy-path render는 반대 flag 상태가 테스트되지 않은 경우 의미가 없다.

Capgo에서 테스트 스택은 다음과 같이 구성된다.

evaluation logic을 단위 테스트한다.
flagged branch를 컴포넌트 테스트한다.
위험한 경로만에 대한 종단 간 테스트를 추가하세요.
기본 대체 값을 명시적으로 확인하세요.

모든 Combination을 목표로 하지 마세요. 일반적으로 그것은 자신의 무게로 붕괴합니다. 사용자가 피해를 입거나 레이아웃이 깨질 수 있는 상태만 테스트하세요.

부채는 실제로 존재하고 QUIETLY 비용이 많이 들 수 있습니다.

code rot의 형태로 된 旧 플래그는 조건문, 주석, 대시보드, 그리고 실행 계획에 남아 있습니다. 그리고 alguien은 몇 달 후에 “임시” branch를 편집하기 때문에 nobody이 제거하지 않았습니다.

실제로 작동하는 청소 규칙은 간단합니다:

문제	어떻게 해야 하나요?
담당자가 없습니다.	플래그가 생성될 때 팀 또는 사람을 assign하세요.
종료 상태가 없습니다.	플래그가 제거되거나 config로 변환되거나 유지될지 결정하세요.
기호 제어는 너무 많습니다.	작은, 좁은 기호로 나누세요.
기호 뒤에 숨겨진 핵심 논리	렌더링 조건문에서 비즈니스 규칙을 제거하세요.

규칙 정리: 1일부터 제거 계획이 있는 목적과 주인, 그리고 기호가 있어야 합니다.

팀이 '신뢰' 문제로 물총을 물리치는 곳이기도 합니다. 기호 이름이 존재하지만 기본값이 잘못되었습니다. 대시보드 항목이 변경되었지만 앱 타입이 변경되지 않았습니다. code 경로가 죽었지만 여전히 접근할 수 있습니다. 따라서 초기 implementation이 간단하게 보였더라도 타입 생성과 레지스트리 검증은 더 큰 시스템에서 중요합니다.

관찰 가능성은 기호가 도움이 되었는지, 그냥 존재했는지 알려줍니다.

기호가 전체 노출에 도달했을 때 롤아웃이 완료된다고 생각하는 것은 오류입니다. 롤아웃이 완료된 것은 팀이 무슨 일이 일어났는지 알 때입니다.

다음 질문들을 추적하세요:

노출: 어떤 사용자가 어떤 변형을 보았습니까?
오류: __CAPGO_KEEP_0__에서 표시된 경로가 더 많은 클라이언트 측 실패를 유발했습니까?
수용: 사용자가 노출된 기능을 사용했습니까?
롤백 신호: __CAPGO_KEEP_0__을 끄기 위한 기준은 무엇입니까?

__CAPGO_KEEP_0__ 플랫폼이 질문에 답하지 못하면, 릴리스 리뷰 시에 여전히 추측해야 합니다.

CI/CD를 사용한 플래그 보안 및 자동화

배포가 잘못되면 명확합니다. 플래그 변경은 quieter하고, 어떤 경우에는 더 위험할 수 있습니다. 왜냐하면 플래그 변경은 code 리뷰 경로를 통하지 않고도 프로덕션 동작을 변경할 수 있기 때문입니다.

플래그 변경을 프로덕션 변경과 같은 것으로 다루세요

기능 플래그는 릴리스 제어입니다. 팀이 프로덕션에서 플래그를 전환할 수 있다면, 그 팀은 사용자가 받는 것을, code 경로가 실행되는 것을, 그리고 때로는 통합이 실행되는 것을 변경할 수 있습니다. 이것은 배포 접근 권한과 같은 discipline을 deserves합니다.

기본 제어는 간단합니다:

역할 기반 접근 권한: 생산 플래그를 변경할 수 있는 사람을 제한하고, 읽기 접근 권한과 편집 접근 권한을 분리합니다.
감사 로그: 플래그를 변경한 사람, 변경한 시간, 변경한 환경을 명확하게 기록합니다.
환경 격리: 테스트 변경이 실시간 트래픽으로 흘러들지 않도록 스테이징, 미리보기, 및 프로덕션 플래그를 구분합니다.
敏感한 결정을 위한 서버측 확인: 클라이언트 플래그는 UI를 숨길 수 있지만, 계정 권한, 특권, 또는 인증을 결정하는 것은 아닙니다.

기본적인 오류는 플래그 대시보드를 공유 스프레드시트처럼 다루는 것입니다. 제품은 고객에게 특정 기능을 활성화합니다. 지원 팀은 불만을 해결하기 위해 플래그를 비활성화합니다. 엔지니어는 배포가 없다고 가정합니다. 그런 설정은 사고를 설명할 때까지 작동합니다.

포장 앱은 위험을 높입니다. 웹 앱에서 code 문제를 빠르게 수정할 수 있습니다. 데스크톱 앱이나 Capacitor 앱에서 code 문제가 이미 기기에 설치되어 있고, remote 플래그가 노출되기를 기다리고 있습니다. code React 모바일 앱을 빌드하는 팀 React mobile apps with Capacitor __CAPGO_KEEP_0__를 승인 규칙에서 더 엄격하게 관리해야 합니다. 롤백은 일반적으로 shipped 기능을 비활성화하는 것보다 바이너리를 교체하는 것보다 더 자주 의미합니다.

기능 배포 프로세스 내에 플래그 연산을 포함시켜야 합니다.

플래그가 배포 프로세스 외부에 존재할 때 신뢰가 떨어집니다. safer 패턴은 기능을 배포하는 동일한 워크플로우에서 관리하는 것입니다.

그것은 일반적으로 다음과 같은 것을 의미합니다.

기능 code와 함께 PR에서 플래그를 생성하거나 업데이트합니다.
CI 동안 remote 레지스트리와 typed 플래그 정의를 검증합니다.
기본값을 환경별로 의도적으로 업데이트합니다.
필수 플래그가 누락되거나 잘못 구성된 경우 릴리스를 차단합니다.
플래그가 만료 날짜 또는 롤아웃 종료 상태를 갖는 경우 클린업 작업을 스케줄합니다.

제품 오류가 플래그로 인해 발생할 수 있다면, CI가 릴리스 전에 설정을 잡아낼 수 있어야 합니다. 이것은 기본값이 누락된 경우, 키 이름이 변경된 경우, 환경 매핑이陈舊한 경우, 그리고 code에 존재하지만 컨트롤 플레인에 존재하지 않는 플래그의 경우를 포함합니다.

CI/CD 워크플로우 구조에 대한 시작점을 찾고 싶다면, Git Action CI/CD 워크플로우 빌드 체크, 배포 게이트, 자동화 단계를 확장할 수 있는 플래그 유효성 검사에 대한坚固한 참조입니다.

비밀을 보호하고 SDK 선택을 재미없게 하세요.

프론트엔드 팀은 플래그 보안을 과도하게 복잡하게 만들고 명백한 부분을 놓치곤 합니다. 일반적으로 브라우저 사용을 위해 설계된 클라이언트 측 SDK 키는 일반적으로 괜찮지만, 관리자 토큰, 쓰기 자격 증명, 환경 관리 키는 그렇지 않습니다. 그들은 CI 또는 백엔드 서비스에서만 속해야 합니다.

실용적인 분리는 간단합니다. 프레젠테이션 변경 및 낮은 위험 실험에 대해 클라이언트 측 평가를 사용하고, 가격, 권한,敏感한 흐름에 대한 죽음 switch, 그리고 로컬 자바스크립트에 신뢰하지 않는 모든 것을 위해 서버 측 평가를 사용하세요.

그 경계는 더 느린 릴리스 환경에서 더 중요합니다. 웹 팀은 빠른 배포로 회복할 수 있지만, 모바일 및 데스크톱 팀은 플래그 시스템이 회복 메커니즘으로 작동해야 합니다. 잘못된 사람들만이 프로덕션 플래그를 편집할 수 있고, CI가 플래그 계약을 검증하지 않는다면 롤백이 빠르게 엉망이 될 것입니다.

Capacitor 및 모바일 앱을 위한 웹 피처 플래그

대부분의 리액트 피처 플래그에 대한 기사들은 즉시 다시 배포할 수 있는 웹 앱을 가정합니다. 그런 가정은 리액트 code이 내장된 순간에 깨집니다. Capacitor, Electron, 또는 다른 패키징된 런타임.

패키징된 앱은 릴리스 수학을 변경합니다.

하이브리드 앱에서 자주 JavaScript, CSS, 자산 및 설정을 사용자들이 즉시 업데이트하지 않는 배ंडल 내에 배송합니다. 기능은 사용자가 기능을 사용하기 전에 기기에 이미 존재할 수 있습니다. 이로 인해 플래그의 역할이 완전히 달라집니다.

최근에 하이브리드 릴리스 전략에 대한 토론에서, existing React flag content는 Capacitor 또는 Electron 앱의 릴리스-리스크 모델을 충분히 다루지 않는다는 점을 지적했습니다. 이 팀의 주요 필요는 플래그, 대상 채널 및 롤백 보호를 결합하는 릴리스 오케스트레이션 층이기 때문입니다. 단순한 on/off switch 대신, 특히 스토어 리뷰 지연을 피할 때 중요합니다.하이브리드 앱 릴리스-리스크 토론).

이것은 정확합니다. 배달된 앱에서 플래그는 조건부 렌더링보다 기기에 이미 배송된 기능의 remote 활성화.

하이브리드 앱에서 플래그는 UI 존재 여부보다 릴리스 타이밍을 제어합니다.

이것은 채널 기반 배포의 중요성도 이유입니다. 앱 셸과 웹 code 릴리스 모델이 함께 의미를 갖게 하려면 Capacitor를 사용하여 React 모바일 앱을 만드는 것은 실용적인 시작점입니다. 플래그는 업데이트를 전달할 때 가장 잘 작동합니다.

모바일 및 데스크톱 팀에서 플래그만으로는 모든 릴리스 문제를 해결할 수 없습니다. 플래그는 __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__

code 업데이트를 플랫폼이 허용하는 경우 전체 스토어 사이클 외부에서 제공하세요.
__CAPGO_KEEP_0__ 업데이트를 채널 또는 대상으로 지정하세요.
__CAPGO_KEEP_0__ 업데이트를 활성화, 롤백 및 단계적 노출에 사용할 플래그를 사용하세요.

라이브 업데이트와 플래그를 함께 사용하면 하이브리드 팀이 웹 스타일의 릴리즈 컨트롤을 더 가까이 갖출 수 있습니다. 그게 필요성의 제거가 아닙니다. 단지 잘못된 경우에 더 많은 레버를 제공하는 것입니다.

Capacitor 또는 Electron 앱을 배포하는 팀이 릴리즈 컨트롤层가 필요하고 있습니다. Capgo __CAPGO_KEEP_0__

React Feature Flags: A Complete Implementation Guide

__CAPGO_KEEP_0__를 사용하여 React Feature Flags: A Complete Implementation Guide __CAPGO_KEEP_0__를 사용하여 React Feature Flags: A Complete Implementation Guide __CAPGO_KEEP_0__를 사용하여 Channels __CAPGO_KEEP_0__를 사용하여 Channels __CAPGO_KEEP_0__ 채널의 구현 세부 사항에 대해 채널 __CAPGO_KEEP_0__ 채널의 구현 세부 사항에 대해 채널 __CAPGO_KEEP_0__ 채널의 구현 세부 사항에 대해 채널 베타 테스트 솔루션 베타 테스트 솔루션의 제품 워크플로에 대해, 그리고 버전 대상 솔루션

리액트 기능 플래그: 완전한 구현 안내서

목차