react native code push
9.0.0
경고
React Native CodePush는 새로운 아키텍처를 지원하지 않습니다. 0.76부터 시작하여 React Native 버전 에서이 플러그인을 사용하려면 새로운 아키텍처에서 옵트 아웃해야합니다.
참고 :이 readme는 최신 버전의 플러그인과 관련이 있습니다. 이전 버전을 사용하는 경우 GitHub 리포의 관련 태그로 전환하여 해당 특정 버전의 문서를보십시오.
이 플러그인은 CodePush Service의 클라이언트 측 통합을 제공하므로 React Native 앱에 동적 업데이트 경험을 쉽게 추가 할 수 있습니다.
React Native 앱은 JavaScript 파일과 함께 제공되는 모든 이미지로 구성되며 Metro Bundler에 의해 함께 번들되어 플랫폼 별 바이너리 (예 : .ipa 또는 .apk 파일)의 일부로 배포됩니다. 앱이 출시되면 JavaScript 코드 (예 : 버그 수정, 새로운 기능 추가) 또는 이미지 자산을 업데이트하면 전체 이진을 다시 컴파일하고 재분배해야합니다. 물론 상점과 관련된 검토 시간이 포함됩니다. 당신은 출판 중입니다.
CodePush 플러그인은 JavaScript 및 이미지를 CodePush 서버에있는 업데이트와 동기화하여 최종 사용자 앞에서 제품 개선을 즉시 개선하는 데 도움이됩니다. 이런 식으로 앱은 오프라인 모바일 경험의 이점과 사용할 수있는 즉시 측면로드 업데이트의 "웹과 같은"민첩성을 얻습니다. 윈윈입니다!
최종 사용자가 항상 기능 버전의 앱을 갖도록하기 위해 CodePush 플러그인은 이전 업데이트의 사본을 유지하므로 실수로 충돌이 포함 된 업데이트를 눌러 자동으로 롤백 할 수 있습니다. 이런 식으로, 당신은 서버에서 롤백 할 기회가 있기 전에 새로운 릴리스 릴리스 민첩성으로 인해 사용자가 차단되지 않을 것이라는 확신을 줄 수 있습니다. 윈윈 윈입니다!
참고 : 기본 코드를 터치하는 제품 변경 (예 : AppDelegate.m / MainActivity.java 파일 수정, 새 플러그인 추가)은 CodePush를 통해 배포 할 수 없으므로 적절한 저장소를 통해 업데이트해야합니다.
우리는 이전 버전의 React Native와 플러그인의 거꾸로 호환성을 유지하기 위해 최선을 다하지만 플랫폼의 특성과 릴리스 간의 변화를 깨뜨리는 것이 존재하기 때문에 CodePush의 특정 버전을 사용해야 할 수도 있습니다. 플러그인 사용중인 React Native의 정확한 버전을 지원하려면 플러그인. 다음 테이블은 어떤 CodePush 플러그인 버전이 공식적으로 각각의 React Native 버전을 지원하는지 설명합니다.
| 기본 버전의 반응 | CodePush 버전 지원 |
|---|---|
| <0.14 | 지원되지 않습니다 |
| v0.14 | v1.3 (안드로이드 지원 소개) |
| V0.15-V0.18 | v1.4-v1.6 (iOS 자산 지원 도입) |
| V0.19-V0.28 | v1.7-v1.17 (안드로이드 자산 지원 도입) |
| V0.29-V0.30 | v1.13-v1.17 (RN Refactored Native Hosting Code) |
| V0.31-V0.33 | v1.14.6-v1.17 (RN Refactored Native Hosting Code) |
| V0.34-V0.35 | v1.15-v1.17 (RN Refactored Native Hosting Code) |
| V0.36-V0.39 | v1.16-v1.17 (RN Refactored 이력서 핸들러) |
| V0.40-V0.42 | v1.17 (RN Refactored iOS 헤더 파일) |
| V0.43-V0.44 | v2.0+ (RN 리팩트 UIMANager 종속성) |
| v0.45 | v3.0+ (RN 리팩토링 인스턴스 관리자 코드) |
| v0.46 | v4.0+ (RN Refactored JS 번들 로더 코드) |
| V0.46-V0.53 | v5.1+ (RN removed unused registration of JS modules) |
| V0.54-V0.55 | v5.3+ (Android Gradle 플러그인 3.x 통합) |
| V0.56-V0.58 | v5.4+ (Android 도구 용 RN 업그레이드 버전) |
| v0.59 | v5.6+ (RN Refactored JS 번들 로더 코드) |
| V0.60-V0.61 | v6.0+ (RN은 자동 링크로 마이그레이션) |
| V0.62-V0.64 | v6.2+ (RN 제거 리버로드) |
| V0.65-V0.70 | v7.0+ (RN 업데이트 된 iPhone-target-version) |
| v0.71 | v8.0+ (RN은 반응-신용 그레이드-플러그로 이동) |
참고 : v5.7.0 보다 낮은 react-native-code-push 버전은 가까운 시일 내에 작동을 멈출 것입니다. 문서에서 더 많은 정보를 찾을 수 있습니다.
우리는 새로운 RN 릴리스에 응답하기 위해 열심히 노력하지만 때때로 우리를 깨뜨립니다. 우리는 각 RN 릴리스 마다이 차트를 업데이트하여 사용자가 "공식"지원이 무엇인지 확인할 수 있도록합니다.
React Native Assets 시스템 (예 : require("./foo.png") 구문을 사용하여)을 사용할 때, 다음 목록은 CodePush를 통해 참조 된 이미지 및 비디오를 업데이트하는 것을 지원하는 핵심 구성 요소 세트 (및 소품)를 나타냅니다.
| 요소 | 소품) |
|---|---|
Image | source |
MapView.Marker(반응-네이티브 맵이 필요합니다 >=O.3.2 ) | image |
ProgressViewIOS | progressImage , trackImage |
TabBarIOS.Item | icon , selectedIcon |
ToolbarAndroid(원시 0.21.0+ 반응) | actions[].icon , logo , overflowIcon |
Video | source |
다음 목록은 정적 이미지 및 비디오에 대한 의존성 (예 : { uri: "foo" } 구문을 사용하여 CodePush를 통해 업데이트되는 자산을 지원하지 않는 구성 요소 세트 (및 소품)를 나타냅니다.
| 요소 | 소품) |
|---|---|
SliderIOS | maximumTrackImage , minimumTrackImage , thumbImage , trackImage |
Video | source |
참조 자산을 지원하는 새로운 핵심 구성 요소가 릴리스되면이 목록을 업데이트하여 사용자가 CodePush를 사용하여 업데이트 할 수있는 정확히 무엇을 알 수 있는지 확인합니다.
참고 : CodePush는 소스 소스에서 require 사용할 때만 비디오 구성 요소와 만 작동합니다. 예를 들어:
< Video source = { require ( "./foo.mp4" ) } / > CodePush 계정을 설정하기위한 일반 목적 "시작"지침을 준수하면 앱의 루트 디렉토리 내에서 다음 명령을 실행하여 CodePush를 고정시킬 수 있습니다.
npm install --save react-native-code-push다른 모든 React Native 플러그인과 마찬가지로 IOS 및 Android에 대한 통합 경험은 다른 플랫폼에 따라 다음 설정 단계를 수행하십시오. 두 플랫폼을 대상으로하는 경우 각 플랫폼에 대해 별도의 CodePush 응용 프로그램을 작성하는 것이 좋습니다.
다른 프로젝트가 CodePush와 어떻게 통합되었는지 확인하려면 커뮤니티가 제공 한 훌륭한 예제 앱을 확인할 수 있습니다. 또한 CodePush + React Native에 빠르게 익숙해 지려면 Bilal Budhani 및/또는 Deepak Sisodiya가 제작 한 멋진 시작 비디오를 확인할 수 있습니다.
참고 :이 안내서는 react-native init 명령을 사용하여 React Native Project를 초기화했다고 가정합니다. 2017 년 3 월 현재, create-react-native-app 명령을 사용하여 React Native Project를 초기화 할 수도 있습니다. 이 명령을 사용하는 경우 프로젝트의 홈 디렉토리에서 npm run eject 실행하여 react-native init 만든 것과 매우 유사한 프로젝트를 얻으십시오.
그런 다음 기본 모듈을 계속 설치하십시오
CodePush 플러그인이 다운로드되고 연결되어 있고 앱이 CodePush를 오른쪽 JS 번들로부터 얻을 수있는 위치를 묻는 앱을 사용하면 다음 정책을 제어하기 위해 앱에 필요한 코드를 추가하는 것입니다.
업데이트를 확인하는시기는 언제 (그리고 얼마나 자주)? (예 : 앱 시작, 설정 페이지에서 버튼을 클릭하여 정기적으로 고정 된 간격으로)
업데이트를 사용할 수 있으면 최종 사용자에게 제시하는 방법은 무엇입니까?
이를 수행하는 가장 간단한 방법은 앱의 루트 구성 요소를 "CodePush-rify"하는 것입니다. 그렇게하려면 다음 두 가지 옵션 중 하나를 선택할 수 있습니다.
옵션 1 : codePush 고차 구성 요소로 루트 구성 요소를 감싸십시오.
클래스 구성 요소의 경우
import codePush from "react-native-code-push" ;
class MyApp extends Component {
}
MyApp = codePush ( MyApp ) ;기능적 구성 요소의 경우
import codePush from "react-native-code-push" ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( MyApp ) ;옵션 2 : ES7 데코레이터 구문 사용 :
참고 : Babel 6.X 보류 제안 제안 업데이트에서는 데코레이터가 아직 지원되지 않습니다. Babel-Preset-React-Native-Stage-0을 설치하고 사용하여 활성화해야 할 수도 있습니다.
클래스 구성 요소의 경우
import codePush from "react-native-code-push" ;
@ codePush
class MyApp extends Component {
}기능적 구성 요소의 경우
import codePush from "react-native-code-push" ;
const MyApp : ( ) => React$Node = ( ) => {
}
export default codePush ( MyApp ) ;기본적으로 CodePush는 모든 앱 시작에서 업데이트를 확인합니다. 업데이트를 사용할 수있는 경우, 다음에 앱을 다시 시작할 때 (최종 사용자 또는 OS에 의해 명시 적으로) 자동으로 다운로드되고 설치되어 최종 사용자에게 최소한의 침습적 경험을 보장합니다. If an available update is mandatory, then it will be installed immediately, ensuring that the end user gets it as soon as possible.
앱이 업데이트를 더 빨리 발견하려면 앱이 배경에서 재개 될 때마다 CodePush 서버와 동기화하도록 선택할 수도 있습니다.
클래스 구성 요소의 경우
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
class MyApp extends Component {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;기능적 구성 요소의 경우
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; 또는 체크가 발생할 때 (버튼 프레스 또는 타이머 간격과 같은)에 대한 세밀한 제어를 원한다면 원하는 SyncOptions 으로 언제든지 CodePush.sync() 호출하고 선택적으로 CodePush의 자동 점검을 끄십시오. 수동 checkFrequency :
let codePushOptions = { checkFrequency : codePush . CheckFrequency . MANUAL } ;
class MyApp extends Component {
onButtonPress ( ) {
codePush . sync ( {
updateDialog : true ,
installMode : codePush . InstallMode . IMMEDIATE
} ) ;
}
render ( ) {
return (
< View >
< TouchableOpacity onPress = { this . onButtonPress } >
< Text > Check for updates < / Text >
< / TouchableOpacity >
< / View >
)
}
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; 업데이트 확인 대화 상자 ( "Active Install")를 표시하려면 사용 가능한 업데이트가 설치 될 때 (즉시 즉시 다시 시작) 또는 다른 방식으로 업데이트 경험을 사용자 정의 할 때 codePush() API 참조를 참조하십시오. 이 기본 동작을 조정하는 방법에 대한 정보.
참고 : Redux 및 Redux Saga를 사용하는 경우 또는 React-Native-Code-Push-Saga 모듈을 사용하여 sync 더 간단하고 관용적으로 호출 할 때 사용자 정의 할 수 있습니다.
Android Google Play 및 iOS App Store에는 응용 프로그램 내에서 CodePush 솔루션을 통합하기 전에 알아야 할 규칙이있는 해당 지침이 있습니다.
장치 및 네트워크 남용 주제의 세 번째 단락은 Google Play의 업데이트 메커니즘 이외의 방법으로 소스 코드 업데이트가 제한되어 있음을 설명합니다. 그러나이 제한은 JavaScript 번들 업데이트에는 적용되지 않습니다.
이 제한은 가상 머신에서 실행되는 코드에는 적용되지 않으며 Android API (예 : WebView 또는 Browser의 JavaScript)에 대한 액세스가 제한적입니다.
CodePush는 JS 번들 만 업데이트하고 기본 코드 부분을 업데이트 할 수 없으므로 완전히 허용합니다.
3.3.2 단락 3.3.2 , 2015 년 Apple Developer Program 라이센스 계약으로 거슬러 올라간 이후 JavaScript 및 자산의 공적 업데이트를 완전히 수행 할 수 있었으며 최신 버전 (20170605)에서 다운로드 할 수있는이 판결은 훨씬 더 넓습니다.
해석 된 코드는 응용 프로그램으로 다운로드 할 수 있지만 그러한 코드만큼 오래 될 수 있습니다. (a) 응용 프로그램의 의도하고 광고 된 목적과 일치하지 않는 기능 또는 기능을 제공하여 응용 프로그램의 주요 목적을 변경하지 않습니다. Store, (b)는 다른 코드 또는 응용 프로그램에 대한 상점 또는 상점을 만들지 않으며 (c) OS의 서명, 샌드 박스 또는 기타 보안 기능을 우회하지 않습니다.
CodePush를 사용하면 푸시 업데이트가 원래 App Store 승인 의도에서 제품을 크게 벗어나지 않는 한이 규칙을 완전히 준수 할 수 있습니다.
Apple의 지침을 계속 준수하기 위해 App Store Distributed Apps는 App Store Review Guidelines에서 다음과 같이 작성되므로 sync 호출 할 때 updateDialog 옵션을 활성화하지 않는 것이 좋습니다.
앱은 사용자가 앱을 평가하고, 앱을 검토하고, 다른 앱 또는 기타 유사한 작업을 다운로드하여 기능, 컨텐츠 또는 앱의 사용에 액세스하도록 강요해서는 안됩니다.
사용자가 새 버전을 다운로드하도록 강요하지는 않기 때문에 반드시 updateDialog 경우는 아니지만 적어도 보여 주기로 결정하면 해당 판결을 알고 있어야합니다.
앱이 사용자에게 구성되고 배포되면 JS 또는 자산 변경을 수행 한 후에는 해제 할 때입니다. 권장되는 방법은 앱 센터 CLI에서 release-react 명령을 사용하는 것입니다. 이는 JavaScript 파일, 자산 파일을 묶고 CodePush 서버에 업데이트를 해제합니다.
참고 : 업데이트를 출시하기 전에 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 라고 가정 할 때 릴리스 번들 생성과 같은 많은 합리적인 기본값을 제공하기 때문에 간단한 워크 플로를 가능하게합니다. 그러나 이러한 모든 기본값은 필요에 따라 점진적인 유연성을 허용하도록 사용자 정의 할 수 있으므로 대부분의 시나리오에 적합합니다.
# Release a mandatory update with a changelog
appcenter codepush release-react -a < ownerName > /MyApp-iOS -m --description " Modified the header color "
# Release an update for an app that uses a non-standard entry file name, and also capture
# the sourcemap file generated by react-native bundle
appcenter codepush release-react -a < ownerName > /MyApp-iOS --entry-file MyApp.js --sourcemap-output ../maps/MyApp.map
# Release a dev Android build to just 1/4 of your end users
appcenter codepush release-react -a < ownerName > /MyApp-Android --rollout 25 --development true
# Release an update that targets users running any 1.1.* binary, as opposed to
# limiting the update to exact version name in the build.gradle file
appcenter codepush release-react -a < ownerName > /MyApp-Android --target-binary-version " ~1.1.0 "
CodePush 클라이언트는 차동 업데이트를 지원하므로 모든 업데이트에서 JS 번들 및 자산을 공개하더라도 최종 사용자는 실제로 필요한 파일 만 다운로드합니다. 이 서비스는이를 자동으로 처리하여 멋진 앱을 작성하는 데 집중할 수 있으며 최종 사용자 다운로드 최적화에 대해 걱정할 수 있습니다.
release-react 명령의 작동 방식에 대한 자세한 내용은 물론 노출되는 다양한 매개 변수에 대한 자세한 내용은 CLI 문서를 참조하십시오. 또한 react-native bundle 명령을 직접 실행하는 것을 원하는 경우 release-react 보다 훨씬 더 유연한 솔루션을 원한다면 자세한 내용은 release 명령을 참조하십시오.
문제가 발생하거나 질문/의견/피드백이있는 경우 Reactiflux의 #Code-Push 채널 내에서 당사를 핑하고 당사에 이메일을 보내거나 아래의 문제 해결 세부 정보를 확인할 수 있습니다.
참고 : CodePush 업데이트는 디버그 모드 이외의 모드로 테스트해야합니다. 디버그 모드에서 React Native App은 항상 Packager에서 생성 한 JS 번들을 다운로드하므로 CodePush가 다운로드 한 JS 번들이 적용되지 않습니다.
시작 문서에서는 특정 배포 키를 사용하여 CodePush 플러그인을 구성하는 방법을 설명했습니다. 그러나 릴리스를 효과적으로 테스트하려면 CodePush 앱 (또는 생성 한 사용자 정의 배포)을 처음 만들 때 자동 생성 된 Staging 및 Production 배포를 활용하는 것이 중요합니다. 이런 식으로, 당신은 당신이 자신을 검증 할 수 없었던 최종 사용자에게 업데이트를 공개하지 않습니다.
참고 : 클라이언트 측 롤백 기능은 충돌이 발생한 릴리스를 설치 한 후 사용자를 차단 해제하는 데 도움이 될 수 있으며 서버 측 롤백 (예 : appcenter codepush rollback )을 사용하면 추가 사용자가 식별되면 잘못된 릴리스를 설치하는 것을 방지 할 수 있습니다. 그러나 처음부터 잘못된 업데이트가 광범위하게 릴리스되는 것을 방지 할 수 있다면 분명히 좋습니다.
Staging 및 Production 배포를 활용하면 다음과 같은 워크 플로를 달성 할 수 있습니다 (자유롭게 사용자 정의하십시오!) :
appcenter codepush release-react 명령 (또는 더 많은 제어가 필요한 경우 appcenter codepush release 사용하여 Staging Deployment에 CodePush 업데이트를 릴리스하십시오.
앱의 스테이징/베타 빌드를 실행하고 서버에서 업데이트를 동기화하고 예상대로 작동하는지 확인하십시오.
appcenter codepush promote Command를 사용하여 Staging 에서 Production 으로 테스트 된 릴리스 홍보
앱의 프로덕션/릴리스 빌드를 실행하고 서버에서 업데이트를 동기화하고 예상대로 작동하는지 확인하십시오.
참고 :보다 신중한 접근 방식을 원한다면 #3의 일부로 "스테이지 롤아웃"을 수행하도록 선택할 수도 있습니다. 이는 업데이트로 추가 잠재적 위험을 완화 할 수 있습니다 ( #2에서 테스트를 마치면 가능한 장치/조건?) 프로덕션 업데이트 만 사용자의 백분율 (예 : appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 )으로 만 사용할 수 있도록합니다. 그런 다음 충돌 보고서 나 고객 피드백이 등장하는지 확인하기 위해 합리적인 시간을 기다린 후 appcenter codepush patch -a <ownerName>/<appName> Production -r 100 실행하여 전체 잠재 고객으로 확장 할 수 있습니다.
위의 단계는 앱의 "스테이징 빌드"및 "프로덕션 빌드"를 참조하십시오. 빌드 프로세스가 이미 "환경"당 고유 한 바이너리를 생성하는 경우 CodePush 배포 키를 바꾸는 것은 앱이 사용하는 다른 서비스에 대한 환경 별 구성을 처리하는 것과 같습니다 (예 : Facebook). 그러나이를 수용하기 위해 빌드 프로세스를 설정하는 방법에 대한 예제 ( 데모 프로젝트 포함 )를 찾고 있다면 앱이 타겟팅하는 플랫폼에 따라 다음 섹션을 참조하십시오.
위의 섹션에서는 최종 사용자에게 광범위하게 발매하기 전에 업데이트를 효과적으로 테스트하기 위해 여러 CodePush 배포를 활용하는 방법을 설명했습니다. 그러나 해당 워크 플로우는 배치 할당을 실제 바이너리에 정적으로 포함시키기 때문에 스테이징 또는 프로덕션 빌드는 해당 배포의 업데이트 만 동기화됩니다. 대부분의 경우 팀, 고객, 이해 관계자 등 만 사전 제작 릴리스와 동기화하기를 원하기 때문에 이것은 충분합니다. 따라서 스테이징과 동기화하는 방법을 알고있는 빌드 만 필요합니다. 그러나 A/B 테스트를 수행하거나 특정 사용자에게 앱의 조기 액세스를 제공하려면 런타임시 특정 사용자 (또는 청중)를 동적으로 배치 할 수있는 것이 매우 유용 할 수 있습니다.
이러한 종류의 워크 플로를 달성하려면 codePush 메소드를 호출 할 때 현재 사용자가 SynCronize를 원하는 배포 키를 지정하기 만하면됩니다. 지정되면이 키는 앱의 Info.plist (iOS) 또는 MainActivity.java (Android) 파일에 제공된 "기본"을 무시합니다. 이를 통해 준비 또는 생산을위한 빌드를 생성 할 수 있으며 필요에 따라 동적으로 "리디렉션"할 수 있습니다.
// Imagine that "userProfile" is a prop that this component received
// which includes the deployment key that the current user should use.
codePush . sync ( { deploymentKey : userProfile . CODEPUSH_KEY } ) ;이러한 변경 사항으로 인해 이제 앱이 현재 사용자에 대한 올바른 배포 키를 결정하는 방법을 선택하는 문제 일뿐입니다. 실제로, 이에 대한 일반적으로 두 가지 솔루션이 있습니다.
언제든지 배포를 변경하기위한 사용자가 가시 메커니즘을 노출시킵니다. 예를 들어, 설정 페이지에는 "베타"액세스를 활성화하기위한 토글이있을 수 있습니다. 이 모델은 사전 제작 업데이트의 개인 정보에 관심이없고, 이전 (및 잠재적으로 버그가 많은) 업데이트가 자신의 유언장 (크롬 채널과 같은 종류의 버그가 많은) 업데이트를 원하는 경우에도 잘 작동합니다. ). 그러나이 솔루션은 사용자의 손에 결정을 내므로 A/B 테스트를 투명하게 수행하는 데 도움이되지 않습니다.
동기화 해야하는 배포를 나타내는 추가 메타 데이터를 사용하여 사용자의 서버 측 프로필에 주석을 달 수 있습니다. 기본적으로 앱은 바이너리 매개 키를 사용할 수 있지만 사용자가 인증 한 후 서버는 다른 배포로 "리디렉션"하도록 선택할 수 있으므로 특정 사용자 또는 그룹을 필요에 따라 다른 배포에 점진적으로 배치 할 수 있습니다. . 서버-응답을 로컬 스토리지에 저장하여 새로운 기본값이되도록 선택할 수도 있습니다. 사용자의 프로필과 함께 키를 저장하는 방법은 전적으로 인증 솔루션 (예 : Auth0, Firebase, Custom DB + REST API)에 달려 있지만 일반적으로 매우 사소한 일입니다.
참고 : 필요한 경우 최종 사용자가 다른 배포를 전환 할 수있는 하이브리드 솔루션을 구현하고 서버가 해당 결정을 무시할 수 있습니다. 이런 식으로, 당신은 당신의 앱이 상자 밖에서 스스로를 업데이트 할 수 있도록하는 "배포 해상도"의 계층 구조를 가지고 있으며, 최종 사용자는 비트에 일찍 액세스하여 보상을 느낄 수 있지만 또한 당신은 또한 비트에 대한 보상을 느낄 수 있지만, 또한 당신은 또한도 가능합니다. 필요에 따라 사용자에게 A/B 테스트를 실행하십시오.
업데이트의 사전 릴리스 테스트를 위해 Staging 배포를 사용하는 것이 좋습니다 (이전 섹션에서 설명한대로). 액세스 (위의 옵션 #1에 설명). 따라서 사용자 정의 앱 배포를 최대한 활용하여 사용자가 귀하의 요구에 맞게 적합 할 수 있도록하는 것이 좋습니다. 예를 들어, 장기 또는 일회성 배포를 생성하고 앱의 변형을 해제 한 다음 특정 사용자를 참여시키기 위해 특정 사용자를 배치 할 수 있습니다.
// #1) Create your new deployment to hold releases of a specific app variant
appcenter codepush deployment add - a < ownerName > / <appName> test-variant-one
// #2) Target any new releases at that custom deployment
appcenter codepush release - react - a < ownerName > / <appName> -d test-variant-one 참고 : 배포의 "설치 메트릭"에보고 된 총 사용자 수는 한 배포에서 다른 배포에서 다른 배포에서 "전환 된"사용자를 고려합니다. 예를 들어, Production 배포가 현재 총 사용자 1 명을 보유하고 있지만 해당 사용자가 Staging 으로 동적으로 전환하면 Production 배포는 총 사용자 0을보고하고 Staging 1 (방금 전환 한 사용자)을보고합니다. 이 동작을 사용하면 런타임 기반 배포 리디렉션 솔루션을 사용하는 경우에도 릴리스 채택을 정확하게 추적 할 수 있습니다.
React Native Community는 시작하고있는 개발자에게 예를 제공 할 수있는 멋진 오픈 소스 앱을 은혜롭게 만들었습니다. 다음은 CodePush를 사용하는 OSS React Native 앱 목록이므로 다른 사람들이 서비스를 어떻게 사용하는지 확인하는 데 사용할 수 있습니다.
또한 React Native + CodePush를 시작하고 멋진 스타터 키트를 찾고 있다면 다음을 확인해야합니다.
참고 : CodePush를 사용하여 React Native App을 개발 한 경우 Open-Source이기도 한 경우 알려주십시오. 우리는이 목록에 추가하고 싶습니다!
sync 메소드에는 많은 진단 로깅이 포함되어 있으므로 사용할 때 문제가 발생하는 경우 먼저 시도하는 가장 좋은 방법은 앱의 출력 로그를 검사하는 것입니다. 이렇게하면 앱이 올바르게 구성되어 있는지 (플러그인이 배포 키를 찾을 수 있습니까?), 앱이 서버에 도달 할 수있는 경우, 사용 가능한 업데이트가 발견되면 업데이트가 성공적으로 다운로드/설치되는 경우, 등. 우리는 가능한 한 직관적이거나 포괄적으로 로깅을 계속 개선하고자하므로 혼란 스럽거나 누락 된 것이 있는지 알려주십시오.
이 로그를 보는 가장 간단한 방법은 각 명령에 대한 플래그 --debug 추가하는 것입니다. 이것은 CodePush 메시지로 필터링 된 로그 스트림을 출력합니다. 이를 통해 플랫폼 별 도구를 사용할 필요없이 문제를 쉽게 식별하거나 잠재적으로 많은 양의 로그를 통과 할 수 있습니다.
또한 플랫폼 별 도구를 사용하여 CodePush 로그를 볼 수 있습니다. Chrome DevTools 콘솔, Xcode 콘솔 (iOS), OS X 콘솔 (iOS) 및/또는 ADB LogCat (Android)을 간단하게 시작하고 [CodePush] 로 접두사를 가진 메시지를 찾습니다.
기본적으로 릴리스 빌드에서 iOS에서 반응 기본 로그가 비활성화되므로 릴리스 빌드에서이를 보려면 AppDelegate.m 파일을 다음과 같이 변경해야합니다.
#import <React/RCTLog.h> 문을 추가하십시오. rn <v0.40 사용 : #import "RCTLog.h"
application:didFinishLaunchingWithOptions
RCTSetLogThreshold (RCTLogLevelInfo);이제 iOS 또는 Android에서 디버그 또는 릴리스 모드에서 CodePush 로그를 볼 수 있습니다. 로그를 검사하는 것이 문제를 표시하지 않는 경우 추가 해결 아이디어는 다음과 같은 일반적인 문제를 참조하십시오.
| 문제 / 증상 | 가능한 해결책 |
|---|---|
| 컴파일 오류 | React Native 버전이 사용중인 CodePush 버전과 호환되는 것을 두 번 확인하십시오. |
iOS 시뮬레이터에서 sync 또는 checkForUpdate 호출 할 때 네트워크 타임 아웃 / 행 | Simulator -> Reset Content and Settings.. 메뉴 항목을 재설정 한 다음 앱을 다시 실행하십시오. |
sync 또는 checkForUpdate 호출 할 때 서버는 404 로 응답합니다. | Info.plist (iOS), build.gradle (Android) 또는 sync / checkForUpdate 로 전달하는 배포 키가 실제로 올바른지 두 번 확인하십시오. appcenter codepush deployment list <ownerName>/<appName> --displayKeys 실행할 수 있으며 앱 배포에 대한 올바른 키를 볼 수 있도록 AppCenter CodePush 배포 목록을 실행할 수 있습니다. |
| 업데이트가 발견되지 않습니다 | 1.0.0 과 같은 실행중인 앱 버전이 CodePush에 업데이트를 발매 할 때 지정된 버전과 일치한다는 것을 두 번 확인하십시오. 또한 앱이 동기화하도록 구성된 것과 동일한 배포를 공개하고 있는지 확인하십시오. |
| 다시 시작 후 업데이트가 표시되지 않습니다 | 앱 시작에서 sync 호출하지 않는 경우 (루트 구성 요소의 componentDidMount 내에서와 같이) App Start에서 notifyApplicationReady 명시 적으로 호출해야합니다. 그렇지 않으면 플러그인이 업데이트가 실패하여 다시 롤백해야합니다. |
| iOS 용 업데이트를 출시했지만 내 Android 앱도 업데이트를 보여 주면서 해를 끼칩니다. | 업데이트를 올바르게 받으려면 각 플랫폼마다 다른 배포 키가 있는지 확인하십시오. |
| 새로운 업데이트를 발표했지만 변경 사항은 반영되지 않습니다 | 디버그 이외의 모드로 앱을 실행하고 있는지 확인하십시오. 디버그 모드에서 React Native App은 항상 Packager에서 생성 한 JS 번들을 다운로드하므로 CodePush가 다운로드 한 JS 번들이 적용되지 않습니다. |
| iOS 시뮬레이터에 대해 앱을 실행할 때 JS 번들이 발견되지 않습니다. | 기본적으로 React Native는 시뮬레이터에 대해 실행할 때 JS 번들을 생성하지 않습니다. 따라서 [CodePush bundleURL] 사용하고 iOS 시뮬레이터를 대상으로하는 경우 nil 결과를 얻을 수 있습니다. 이 문제는 RN 0.22.0으로 수정되지만 릴리스 빌드에만 수정됩니다. 이 변경 사항을 로컬로 수행 하여이 시나리오를 차단 해제 할 수 있습니다. |
CodePush CLI를 사용하여 업데이트를 "수동으로"릴리스 할 수있을뿐만 아니라 앱에 업데이트를 전달하기위한 반복 가능하고 지속 가능한 솔루션을 만드는 것이 중요하다고 생각합니다. 그렇게하면, 당신과 당신의 팀이 민첩한 배포를 수행하는 리듬을 만들고 유지할 수있을만큼 간단합니다. CodePush 기반 CD 파이프 라인 설정을 돕기 위해 다양한 CI 서버와의 다음 통합을 참조하십시오.
또한 CodePush를 포함하여 완전한 모바일 CI/CD 워크 플로우가 어떻게 보일 수 있는지에 대한 자세한 내용은 Zeemee Engineering Team 의이 훌륭한 기사를 확인하십시오.
이 모듈은 *.d.ts 파일을 NPM 패키지의 일부로 선적하여 간단히 import 편집자 (Visual Studio Code와 같은)를 지원하는 Intellisense를받을 수 있으며 컴파일 타임 타임 유형을 확인할 수 있습니다. TypeScript 사용. 대부분의 경우,이 동작은 tsconfig.json 파일의 target 또는 module 컴파일러 옵션의 값으로 es6 지정하면이 동작을 상자에서만 꺼내야합니다. moduleResolution node 옵션. 이를 통해 TypeScript 컴파일러가 가져온 모듈의 유형 정의에 대해 node_modules 내에서 볼 수 있습니다. 그렇지 않으면 react-native-code-push 모듈을 가져올 때 다음과 같은 오류가 발생합니다. error TS2307: Cannot find module 'react-native-code-push' .
이 프로젝트는 Microsoft 오픈 소스 행동 강령을 채택했습니다. 자세한 내용은 추가 질문이나 의견이 있으면 행동 강령 FAQ 또는 [email protected]에 문의하십시오.
