[번역] react-native-code-push

박은정·2023년 2월 28일

react native

TIL

목록 보기

67/70

원문: https://github.com/microsoft/react-native-code-push

참고: 해당 README는 당사 플러그인의 최신 버전만 관련이 있습니다. 이전 버전을 사용하는 경우 깃허브 레포에서 관련 태그로 전환해서 해당 버전의 문서를 확인하세요.

그래서... 회사에서 사용하는 7.0.5버전 기준으로 README를 확인했습니다.

이 플러그인은 코드푸시 서비스에 대한 클라이언트 측 통합을 제공해서 → 동적인 업데이트 환경을 리액트 네이티브 앱에 쉽게 추가할 수 있게 도와줍니다.

동작원리

리액트 네이티브 앱은 자바스크립트 파일과 함께 메트로 번들러에 의해 번들되고 .ipa, .apk 같은 플랫폼별 바이너리의 일부로 배포되는 이미지로 구성됩니다.
앱이 출시되면 버그수정이나 새로운 기능추가 같은 자바스크립트 코드나 이미지 assets을 업데이트하기 위해 전체 바이너리를 다시 컴파일하고 재배포해야 합니다. 물론 게시하려는 스토어 (구글플레이나 앱스토어)와 관련된 검토 시간도 포함됩니다.

코드푸시 플러그인은 사용자가 코드푸시 서버에 릴리스하는 업데이트와 자바스크립트 및 이미지를 동기화해서 → 최종 사용자에게 개선된 앱을 제공할 수 있게 도와줍니다.
이를 통해 앱은 오프라인 모바일 환경의 장점과 업데이트가 제공하는 즉시 웹처럼 사이드 로딩의 민첩성을 얻을 수 있습니다.

최종 사용자가 항상 앱의 작동 버전을 사용할 수 있도록 코드푸시 플러그인은 이전 업데이트의 복사본을 유지해서 → 충돌을 포함한 업데이트를 실수로 푸시할 경우 자동으로 롤백할 수 있습니다.
이렇게 하면 새로 발견된 릴리스 민첩성으로 인해 서버에서 롤백하기 전에 사용자가 차단당하지 않습니다.

참고: ~~AppDelegate.m, MainActivity.java 파일수정이나 새로운 플러그인 추가같은~~ 네이티브 코드를 건들인 모든 변경사항은 코드푸시를 통해 변경할 수 없기 때문에 각 플랫폼에 맞는 스토어를 통해 업데이트를 해야 합니다.

지원되는 리액트 네이티브 플랫폼

iOS (7+)
Android (4.1+) on TLS 1.2 compatible devices
Windows (UWP)

우리는 이전 버전의 리액트 네이티브 플러그인의 역호환성을 유지하기 위해 최선을 다하지만, 플랫폼의 특성과 릴리스 간의 변경 사항이 발생하기 때문에 → 사용 중인 리액트 네이티브의 정확한 버전을 지원하기 위해 → 특정 버전의 코드푸시 플러그인을 사용해야 할 수도 있습니다.

각 리액트 네이티브 버전을 공식적으로 지원하는 코드푸시 플러그인 버전 요약 표

리액트네이티브 버전	지원되는 코드푸시 버전
<0.14	지원안함
v0.14	v1.3 (AOS 지원도입)
v0.15-v0.18	v1.4-v1.6 (iOS assets 지원도입)
v0.19-v0.28	v1.7-v1.17 (AOS assets 지원도입)
v0.29-v0.30	v1.13-v1.17 (RN에서 네이티브 호스팅 코드 리팩토링함)
v0.31-v0.33	v1.14.6-v1.17 (RN에서 네이티브 호스팅 코드 리팩토링함)
v0.34-v0.35	v1.15-v1.17 (RN에서 네이티브 호스팅 코드 리팩토링함)
v0.36-v0.39	v1.16-v1.17 (RN에서 resume handler 리팩토링함)
v0.40-v0.42	v1.17 (RN에서 iOS 헤더파일 리팩토링함)
v0.43-v0.44	v2.0+ (RN에서 UI매니저 의존성 리팩토링함)
v0.45	v3.0+ (RN에서 인스턴스 매니저 코드 리팩토링함)
v0.46	v4.0+ (RN에서 JS번들 로더 코드 리팩토링함)
v0.46-v0.53	v5.1+ (RN에서 사용되지 않는 등록된 JS모듈을 삭제함)
v0.54-v0.55	v5.3+ (AOS Gradle 플러그인 3.x 통합)
v0.56-v0.58	v5.4+ (AOS tools을 위한 RN의 버전 업그레이트)
v0.59	v5.6+ (RN에서 JS번들 로더 코드 리팩토링함)
v0.60-v0.61	v6.0+ (RN에서 Autolinking지원함)
v0.62-v0.64	v6.2+ (RN에서 LiveReload제거함)
v0.65	v7.2+ (RN iPhone-target-version 업데이트)

참고: v5.7.0 이전 버전의 react-native-code-push 는 곧 지원을 중단할 겁니다. 자세한 내용은 설명서에서 확인할 수 있습니다.

우리는 새로운 RN 릴리스에 대응하기 위해 열심히 노력하지만, 가끔씩 RN이 이를 방해하기 때문에 "공식"지원이 뭔지 확인할 수 있도록 각 RN 릴리스마다 해당 표를 업데이트할 예정입니다.

지원되는 컴포넌트

코드푸시를 통해 참조된 이미지와 비디오 업데이트 지원하는 컴포넌트와 props

리액트 네이티브에서 require('./이미지.png') 구문을 사용하는 assets 시스템을 사용할 때, 다음 목록은 코드푸시를 통해 참조된 이미지와 비디오를 업데이트하는 것을 지원하는 핵심 컴포넌트 및 props입니다.

Component	Prop(s)
Image	source
MapView.Marker (Requires react-native-maps >=O.3.2)	image
ProgressViewIOS	progressImage, trackImage
TabBarIOS.Item	icon, selectedIcon
ToolbarAndroid(React Native 0.21.0+)	`actions[].icon`, logo, overflowIcon
Video	source

코드푸시를 통해 업데이트를 지원하지 않는 컴포넌트와 props

{ uri: '/이미지.png'} 구문을 사용하는 정적 이미지나 비디오를 의존하기 때문에 현재 코드푸시를 통해 업데이트되는 assets를 지원하지 않는 컴포넌트와 props입니다.

Component	Prop(s)
SliderIOS	maximumTrackImage, minimumTrackImage, thumbImage, trackImage
Video	source

assets 탐조를 지원하는 새로운 핵심 컴포넌트가 출시되면 이 목록을 업데이트해서 사용자가 코드푸시를 사용해서 정확히 어떤걸 업데이트할 수 있는지 확인할 수 있게 할겁니다.

참고: 코드푸시는 source props에서 require()를 사용할 때만 비디오 컴포넌트와 함께 작동합니다.

<Video source={require('./비디오.mp4')}/>

코드푸시 시작하기

코드푸시 계정을 설정하기 위한 일반적인 "getting started" 지침을 따르고 나면 → 앱의 루트 디렉토리에서 다음 명령을 실행해서 코드푸시가 적용된 RN앱을 시작할 수 있습니다.

$ npm install --save react-native-code-push

다른 모든 리액트 네이티브 플러그인과 마찬가지로 iOS와 AOS의 통합환경은 다르기 때문에 대상 플랫폼에 따라 다음 설정 단계를 수행해야 합니다.
두 플랫폼을 모두 대상으로 하는 경우 각 플랫폼에 대해 별도의 코드푸시 응용 프로그램을 만드는 것이 좋습니다.

만약 다른 프로젝트들이 어떻게 코드푸시와 통합되었는지 보고 싶다면, 커뮤니티가 제공하는 예시 앱들을 확인할 수 있습니다.
또한 코드푸시 + 리액트 네이티브에 빠르게 익숙해지고 싶다면 Billal Budhani 및/또는 Deepak Sisodiya가 만든 시작 비디오를 확인할 수 있습니다.

참고: 이 가이드는 react-native init 명령어를 사용해서 RN 프로젝트를 초기화했다고 가정합니다. 2017년 3월기준 create-react-native-app 명령을 사용해서 RN 프로젝트를 초기화할 수도 있었습니다. 해당 명령을 사용하는 경우 프로젝트의 홈 디렉토리에서 npm run emject을 실행해서 react-native가 생성한 것과 매우 유사한 프로젝트에 적용해야 합니다.

그런 다음 네이티브 모듈을 설치해야 합니다.

플러그인 사용

코드푸시 플러그인을 다운로드해서 연결하고 앱이 올바른 JS번들을 어디서 가져올지 묻는 상황에서, 남은 것은 다음 정책을 제어하는 데 필요한 코드를 앱에 추가하는 것뿐입니다.

언제(그리고 얼마나 자주) 업데이트를 확인되나?
- 예: 앱 시작, 설정 페이지의 버튼 클릭에 대한 응답, 일정한 간격으로 주기적으로
업데이트를 사용할 수 있는 경우 최종 사용자에게 어떻게 제공해야되나?

가장 간단한 방법은 앱의 루트 컴포넌트를 코드푸시하는 것입니다.
이렇게 하면 다음 두 가지 옵션 중 하나를 선택할 수 있습니다.

1. 옵션 1: 루트 컴포넌트를 코드푸시 high-order 커포넌트로 감쌉니다.

// class형 컴포넌트
import codePush from 'react-native-code-push';
class App extends Component {};
App = codePush(App);

// 함수형 컴포넌트
import codePush from 'react-native-code-push';
let App: ()=>React$Node=()=>{};
App = codePush(App);

2. 옵션 2: ES7 decorator 구문사용

참고: proposal 업데이트가 진행중인 Babel 6.x 에서는 decorator가 지원되지 않습니다. babel-preset-react-native-stage-0 패키지를 설치하고 사용해서 활성화해야 decorator를 할 수 있습니다.

// class형 컴포넌트
import codePush from 'react-native-code-push';

@codePush
class App extends Component {}

// 함수형 컴포넌트
import codePush from 'react-native-code-push';
const App: () => React$Node = () => {};
export default codePush(App);

기본적으로 코드푸시는 모든 앱이 시작할 때 업데이트를 확인합니다.
업데이트를 사용할 수 있는 경우 앱 유저 ~~최종 사용자~~ 나 OS에서 자동으로 다운로드되고 다음 번에 앱을 다시 시작할 때 설치됩니다. 이를 통해 앱 유저는 최소한의 침해 경험을 얻을 수 있습니다.
사용 가능한 업데이트가 필수인 경우, 업데이트가 즉시 설치되어 앱 유저가 가능한 빨리 업데이트를 받을 수있습니다.

앱에서 업데이트를 더 빨리 검색하려면 앱이 백그라운드에서 다시 시작될 때마다 코드푸시 서버와 동기화하도록 선택할 수도 있습니다.

// class형
let codePushOptions = { checkFrequency: codePush.CheckFrequency,ON_APP_RESUME };
class App extends Components {};
App = codePush(codePushOptions)(App);

// 함수형
import codePushOptions = { checkFrequency: codePush.CheckFrequency.ON_APP_RESUME };
let App = React$Node = () => {};
App = codePush(codePushOptions)(App);

~~frequency: 주파수, 진동수, 검사빈도~~

또는 버튼이나 타이머 간격처럼 버전검사를 할때 세부적으로 제어하려면 → 원하는 SyncOptions로 언제든지 CodePush.sync() 를 호출하고 수동 검사 빈도 manual checkFrequency 를 지정해서 선택적으로 CodePush의 자동검사를 해제할 수 있습니다.

let codePushOptions = { checkFrequency: codePush.CheckFrequency.MANUAL };

class App extends Components {
	onButtonPress() {
    	codePush.sync({ updateDialog: true, installMode: codePush.InstallMode.IMMEDIATE });
    }
  	render() {
    	return (
        	<View>
          		<TouchableOpacity onPress={this.onButtonPress}>
          			<Text>업데이트체크</Text>
          		</TouchableOpacity>
          	</View>
        );
    }
};

App = codePush(codePushOptions)(App);

업데이트를 확인하는 설치버튼 활성화된 dialog을 표시하거나
즉시 강제 재시작처럼 사용가능한 업데이트가 설치된 시기를 구성하거나

다른 방법으로 업데이트 환경을 사용자 지정하려면 codePush() API 참조에서 이 기본 동작을 수정하는 방법을 참조하세요.

참고: Redux 및 Redux Saga를 사용하는 경우 react-native-code-push-saga 모듈을 사용할 수 있습니다. 해당 모듈을 사용하면 동기화가 더 단순하고 관용적인 방식으로 호출할 때 사용자 지정할 수 있습니다.

스토어 가이드라인 준수

AOS 구글플레이 및 iOS 앱스토어에는 코드푸시 솔루션을 애플리케이션에 통합하기 전에 알아야 할 규칙이 있는 해당 지침이 있습니다.

Google Play

장치 및 네트워크 남용 항목의 세 번째 단락에서는 구글플레이의 업데이트 메커니즘이 아닌 다른 방법으로 소스 코드를 업데이트하는 것이 제한된다고 설명합니다.
하지만 이 제한은 자바스크립트 번들 업데이트에는 적용되지 않습니다.

가상 머신에서 실행하며 웹뷰 또는 브라우저의 JS같은 Android API에 대한 접근이 제한된 코드에는 적용되지 않습니다.

코드푸시는 JS번들만 업데이트하고 네이티브 코드 부분은 업데이트를 할 수 없기 때문에 구글플레이에서는 코드푸시를 통한 업데이트를 완전히 허용합니다.

App Store

단락 3.3.2 2015년 애플 개발자 프로그램 사용권 계약에서 자바스크립트와 assets의 over-the-air ~~ON-AIR~~ 업데이트를 완전히 허용했기 때문에 여기서 다운로드 할 수 있는 최신버전(20170605)에서는 이 판결이 훨씬 더 광범위합니다.

해석된 코드는 애플리케이션에 다운로드할 수 있지만, 이러한 코드가 있는 경우에만 다운로드할 수 있습니다.
(a) 앱 스토어에 제출된 애플리케이션의 의도 및 광고 목적과 일치하지 않는 기능을 제공함으로써 애플리케이션의 기본 목적을 변경하지 않으며
(b) 다른 코드를 위한 스토어 혹은 스토어 프론트를 만들지 않습니다.
(c) OS의 서명, 샌드박스 또는 기타 보안 기능을 우회하지 않습니다.

코드푸시를 사용하면 푸시하는 업데이트가 원래 앱스토어 승인 의도에서 제품을 크게 벗어나지 않은 한, 이러한 규칙을 완전히 준수할 수 있습니다.

앱스토어 리뷰 가이드라인에는 다음과 같이 기록되어 있으므로 앱스토어에서 배포된 앱 app store-distributed 에서 sync() 함수를 호출할 때 updateDialog 옵션을 활성화하지 않는게 좋습니다.

앱은 앱 기능, 콘텐츠 또는 사용에 접근하기 위해 사용자에게 앱 평가, 앱 검토, 다른 앱 다운로드 또는 기타 유사한 작업을 강요해서는 안됩니다.

사용자가 새로운 버전을 다운로드하도록 강제하지 않기 때문에 updateDialog의 경우에는 그렇지 않지만 적어도 표시하기로 결정했다면 해당 판결을 알아야 합니다.

업데이트 릴리스

앱이 구성되어 사용자에게 배포되고 JS 또는 assets을 변경한 후에는 이를 릴리스할 때입니다.
App Center CLI에서 release-react 명령을 사용해서 JS파일, assets파일을 번들하고 코드푸시 서버로 업데이트를 릴리스하는 것이 좋습니다.

참고: 업데이트 릴리스를 시작하려면 먼저 appcenter login 명령을 실행해서 App Center에 로그인해야 합니다.

가장 기본적인 형식에서 이 명령어는 하나의 매개변수, 즉 소유자이름 + '/' + 앱이름 이 필요합니다.

appcenter codepush release-react -a <ownerName>/<appName>

appcenter codepush release-react -a <ownerName>/MyApp-iOS
appcenter codepush release-react -a <ownerName>/MyApp-Android

release-react 명령은 iOS에서 앱의 엔트리 파일이 index.ios.js 또는 index.js 라고 가정하는 릴리스 번들 생성과 같은 많은 합리적인 기본값을 제공하기 때문에 이처럼 간단한 워크플로우를 가능하게 합니다.
하지만 이러한 모든 기본값은 필요에 따라 증분 유연성 incremental flexibility 을 허용하도록 사용자 정의할 수 있기 때문에 → 대부분의 시나리오에 적합합니다.

# 변경로그가 포함된 필수 업데이트 릴리스
appcenter codepush release-react -a <ownerName>/MyApp-iOS  -m --description "Modified the header color"

# 비표준 항목 파일 이름을 사용하는 앱에 대한 업데이트를 릴리스하고 react-native 번들에서 생성된 소스 맵 파일도 캡처합니다.
appcenter codepush release-react -a <ownerName>/MyApp-iOS --entry-file MyApp.js --sourcemap-output ../maps/MyApp.map

# 최종 사용자의 1/4에게만 개발 android 빌드 공개
appcenter codepush release-react -a <ownerName>/MyApp-Android  --rollout 25 --development true

# build.gradle 파일의 정확한 버전 이름으로 업데이트를 제한하는 대신, 1.1.x 이진(바이너리)을 실행하는 앱을 대상으로 업데이트를 릴리스합니다.
appcenter codepush release-react -a <ownerName>/MyApp-Android  --target-binary-version "~1.1.0"

코드푸시 클라이언트는 차등 업데이트를 지원하기 때문에 → 모든 업데이트에서 JS번들 및 assets를 릴리스하더라도 앱 유저는 실제로 필요한 파일만 다운로드할 수 있습니다.
이 서비스는 이를 자동으로 처리하기 때문에 → 개발자는 앱을 만드는 데 집중할 수 있고 앱 유저 다운로드 최적화에 집중할 수 있습니다.

release-react 명령의 작동방식과 명령이 표시하는 다양한 매개변수에 대한 자세한 내용은 CLI 문서를 참조하세요.
또한 react-native bundle 명령 실행을 집접 처리해서 release-react 보다 훨씬 유연한 솔루션을 원하는 경우에는 release 명령어를 참조하세요.

문제가 발생하거나 질문/댓글/피드백이 있는 경우 Reactiflux의 #code-push 채널 내에서 ping을 보내거나 아래 문제 해결 세부 정보를 확인할 수 있습니다.

참고: 코드푸시 업데이트는 디버그 모드 이외의 모드에서 테스트해야 합니다. 디버그 모드에서 RN앱은 항상 패키저에서 생성한 JS번들을 다운로드하기 때문에 코드푸시에서 다운로드한 JS번들은 적용되지 않습니다.

다중 배포 테스트

시작 설명서에는 특정 배포 키를 사용해서 코드푸시 플러그인을 구성하는 방법을 설명했습니다.
하지만 릴리스를 효과적으로 테스트하려면 코드푸시앱을 처음 만들 때 자동으로 생성되는 스테이징 및 프로덕션 배포 (또는 직접 생성한 커스텀 배포)를 활용하는 것이 중요합니다.
이렇게 하면 앱 유저에게 자신을 검증할 수 없는 업데이트를 릴리스하지 않습니다.

참고:
클라이언트 측 롤백 기능을 사용하면 → 충돌이 발생한 릴리스를 설치한 후 개발자의 차단해제를 할 수 있으며,
appcenter 코드푸시 롤백처럼 서버 측 롤백을 사용하면 → 잘못된 릴리스를 식별한 후 개발자가 추가적으로 설치하는 것을 방지할 수 있습니다.
하지만 애초에 잘못된 업데이트가 광범위하게 공개되는 것을 방지할 수 있다면 분명히 더 좋습니다.

스테이징 및 프로덕션 배포를 활용하면 다음과 같은 워크플로우를 구현할 수 있습니다.

appcenter codepush release-react 명령을 사용해서 코드푸시 업데이트를 스테이징 배포 릴리스 (또는 추가 제어가 필요한 경우 appcenter codepush release )
앱의 스테이징/베타 빌드를 실행하고 서버에서 업데이트를 동기화하고 예상대로 작동되는지 확인합니다.
appcenter codepush promot 명령을 사용해서 테스트된 릴리스를 스테이징 → 프로덕션으로 업그레이드
애플리케이션의 프로덕션/릴리스 빌드를 실행하고 서버에서 업데이트를 동기화하고 예상대로 작동되는지 확인

참고:
보다 신중한 접근 방식을 원한다면 3단계의 일부로 "단계별 롤아웃"을 선택할 수도 있습니다.
2단계의 테스트에서 가능한 모든 장치나 조건을 다루었다면, 이를 통해 일부 앱에만 프로덕션 업데이트를 사용해서 추가적인 잠재적 위험을 완화할 수 있습니다.
appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20
그런 다음, 충돌 보고서나 고객 필드백이 있는지 확인하기 위해 → 적절한 시간을 기다린 후, 앱 센터 코드푸시 패치인 appcenter codepush patch -a <ownerName>/<appName> Production -r 100 을 실행해서 전체 앱으로 확장할 수 있습니다.

위의 단계는 앱의 스테이지 빌드 및 프로덕션 빌드 를 의미합니다.
빌드 프로세스가 이미 환경 별로 고유한 바이너리를 생성한 경우, 코드푸시 배포 키를 스왑하는 것은 페이스북처럼 앱이 사용하는 다른 서비스에 대한 환경별 구성을 처리하는 방법과 동일하기 때문에 더 이상 읽을 필요가 없습니다.
하지만 이를 적용하기 위해 데모 프로젝트를 포함한 빌드 프로세스를 설정하는 방법에 대한 예시를 찾는 경우, 앱이 타겟팅하는 플랫폼에 대한 다음 섹션을 참조하세요.

Android
iOS

동적 배포 할당

위 섹션에서는 업데이트를 앱 유저에게 광범위하게 릴리스하기 전에 여러 코드푸시 배포를 활용해서 업데이트를 효과적으로 테스트하는 방법을 설명했습니다.
하지만 이 워크플로우는 실제 바이너리 배포 할당을 정적으로 포함하기 때문에 스테이징 또는 프로덕션 빌드는 해당 배포의 업데이트만 동기화합니다.
대부분의 경우 팀, 고객, 이해관계자 등이 사전 프로덕션 릴리스와 동기화하는 것만 원하기 때문에 스테이징과 동기화하는 방법을 아는 빌드만 필요하기 때문에 이정도면 충분합니다.
하지만 A/B 테스트를 수행하거나 특정 사용자에게 앱에 대한 조기 액세스를 제공하려면 → 런타임에 특정 사용자나 대상자를 특정 배포에 동적으로 배치하는 것이 매우 유용할 수 있습니다.

이러한 워크플로우를 수행하려면 코드푸시 메서드를 호출할 때 현재 사용자가 동기화할 배포 키를 지정하기만 하면 됩니다.
해당 키를 지정하려면 앱의 Info.plist (iOS) 또는 MainActivity.java (AOS) 파일에 제공된 "기본(default)" 키를 재정의합니다.
이를 통해 필요에 따라 동적으로 "재연결"할 수 있는 스테이징 또는 프로덕션 빌드를 생성할 수 있습니다.

// "userProfile"이 현재 사용자가 사용해야 하는 배포 키를 포함해서, 이 컴포넌트가 받은 props라고 가정합시다
codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });

이러한 변경사항이 적용되면, 이제 앱이 현재 유저에게 적합한 배포 키를 결정하는 방법을 고민하면 되는데, 일반적으로는 2가지 방법이 있습니다.

언제든지 배포를 변경할 수 있는 사용자 표시 메커니즘을 표시합니다.
예를 들어, 설정 페이지에 "베타"엑세서를 활성화하기 위한 토글이 있을 수 있습니다.
이 모델은 사전 프로덕션 업데이트의 개인 정보 보호에 관심이 없고, 파워 유저가 자신의 의지로 이전하고 잠재적으로 버그가 있는, 크롬채널처럼 업데이트를 선택할 수 있는 경우 잘 작동합니다.
하지만 해당 방법은 유저의 결정에 맡기기 때문에 A/B 테스트를 투명하게 수행하는데 도움이 되지 않습니다.
사용자가 동기화해야 하는 배포를 나타내는 추가 메타데이터 조각을 사용해서 사용자의 서버 프로필에 주석을 달 수 있습니다.
기본적으로 앱은 바이너리 내장 키만 사용할 수 있지만, 사용자가 인증한 후 서버는 사용자를 다른 배포로 재연결하도록 선택할 수 있으며, 이를 통해 필요에 따라 특정 사용자나 그룹을 다른 배포에 점진적으로 배치할 수 있습니다.
서버 응답을 로컬스토리지에 저장해서 새로운 기본값이 되도록 선택할 수도 있습니다.
사용자 프로필과함께 키를 저장하는 방법은 ~~Auth0, Firebase, DB + REST API 같은~~ 인증 솔루션에 전적으로 달려있지만 일반적으로 매우 사소한 작업입니다.

참고:
필요한 경우 앱유저가 서로 다른 배포 환경을 전환할 수 있는 동시에, 서버가 해당 결정을 무시할 수 있는 하이브리드 솔루션을 구현할 수도 있습니다.
이렇게 하면 앱이 즉시 자동으로 업데이트할 수 있는 "배포 해결"계층이 있으며, 앱유저는 비트에 대한 조기 액세스를 통해 보상을 받을 수 있지만, 필요에 따라 사용자에게 A/B 테스트를 실행할 수도 있습니다.

업데이트의 사전 릴리스 테스트를 위해 스테이징 배포를 사용하는 것이 좋습니다.
따라서 사용자에 대한 A/B 테스트를 수행하기 위해 스테이징 배포를 사용하는 것은 반드시 의미가 없습니다.
따라서 필요에 따라 사용자를 세분화할 수 있도록 커스텀 앱 배포를 최대한 활용하는 것이 좋습니다.
예를 들어, 장기 배포 또는 일회성 배포를 만들고, 앱의 변형을 배포한 다음 특정 사용자를 해당 사용자에 배치해서 해당 사용자가 어떻게 참여했는지 확인할 수 있습니다.

// #1) 특정 앱버전의 릴리스를 보유할 새 배포 생성
appcenter codepush deployment add -a <ownerName>/<appName> test-variant-one

// #2) 해당 사용자 지정 배포에서 모든 새 릴리스 대상 지정
appcenter codepush release-react -a <ownerName>/<appName> -d test-variant-one

*참고:
배포의 "Install Metrics"에 보고된 총 사용자 수에는 배포 간에 "전환"한 사용자가 고려됩니다.
예를 들어, 현재 운영 배포 환경에서 총 사용자가 1명이라고 보고했지만 해당 사용자를 동적으로 스테이징으로 전환하면 운영 배포 환경에서는 총 사용자가 0명이라고 보고되는 반면, 스테이징 환경에서는 이제 막 전환한 사용자 1명으로 보고됩니다.
이 동작을 통해 런타임 기반 배포 리디렉션 방법을 사용하는 경우에도 릴리스 채택을 정확하게 추적할 수 있습니다.