react native code push
9.0.0
Avertissement
React Native Codepush ne prendra pas en charge une nouvelle architecture. Afin d'utiliser ce plugin sur les versions natives React à partir de 0,76, vous devrez vous retirer de la nouvelle architecture.
Remarque: Ce ReadMe n'est pertinent que pour la dernière version de notre plugin. Si vous utilisez une version plus ancienne, veuillez passer à la balise pertinente sur notre dépôt GitHub pour afficher les documents pour cette version particulière.
Ce plugin fournit une intégration côté client pour le service Codepush, vous permettant d'ajouter facilement une expérience de mise à jour dynamique à vos applications natives React.
Une application Native React est composée de fichiers JavaScript et de toutes les images qui l'accompagnent, qui sont regroupées par le métro et distribuées dans le cadre d'un binaire spécifique à la plate-forme (c'est-à-dire un fichier .ipa ou .apk ). Une fois l'application publiée, la mise à jour soit le code JavaScript (par exemple, la fabrication de corrections de bogues, l'ajout de nouvelles fonctionnalités) ou les actifs d'image, vous oblige à recompiler et à redistribuer l'intégralité du binaire, ce qui, bien sûr, comprend tout temps de révision associé au magasin (s) vous publiez.
Le plugin Codepush aide à obtenir instantanément les améliorations des produits devant vos utilisateurs finaux, en gardant votre javascript et vos images synchronisées avec les mises à jour que vous publiez sur le serveur Codepush. De cette façon, votre application bénéficie des avantages d'une expérience mobile hors ligne, ainsi que de l'agilité "de type Web" des mises à jour de chargement latérales dès qu'elles sont disponibles. C'est un gagnant-gagnant!
Afin de vous assurer que vos utilisateurs finaux ont toujours une version fonctionnelle de votre application, le plugin Codepush maintient une copie de la mise à jour précédente, de sorte que dans le cas où vous poussez accidentellement une mise à jour qui comprend un crash, il peut automatiquement revenir. De cette façon, vous pouvez être assuré que votre nouvelle agilité de version ne fera pas bloquer les utilisateurs avant d'avoir la possibilité de revenir sur le serveur. C'est un gagnant-gagnant!
Remarque: Toute modification du produit qui touche le code natif (par exemple, modifiant votre fichier AppDelegate.m / MainActivity.java , ajoutant un nouveau plugin) ne peut pas être distribuée via Codepush et, par conséquent, doit être mise à jour via le ou les magasins appropriés.
Nous faisons de notre mieux pour maintenir la compatibilité en arrière de notre plugin avec les versions précédentes de React Native, mais en raison de la nature de la plate-forme et de l'existence de changements de rupture entre les versions, il est possible que vous ayez besoin d'utiliser une version spécifique du codepush Plugin afin de prendre en charge la version exacte de React Native que vous utilisez. Le tableau suivant décrit que les versions du plugin CodePush soutiennent officiellement les versions natives React respectives:
| React Version native (s) | Support Codepush version (s) |
|---|---|
| <0,14 | Non pris en charge |
| v0.14 | v1.3 (support Android introduit) |
| v0.15-v0.18 | v1.4-v1.6 (support d'origine iOS) |
| v0.19-v0.28 | v1.7-v1.17 (support d'actifs Android) |
| V0.29-V0.30 | v1.13-v1.17 (code d'hébergement natif refactorisé) |
| v0.31-v0.33 | v1.14.6-v1.17 (code d'hébergement natif refactorisé) |
| v0.34-v0.35 | v1.15-v1.17 (code d'hébergement natif refactorisé) |
| v0.36-v0.39 | v1.16-v1.17 (gestionnaire de CV refactorisé) |
| V0.40-V0.42 | v1.17 (fichiers d'en-tête iOS refactorisés RN) |
| v0.43-v0.44 | v2.0 + (RN dépend des dépendances Uimanager) |
| v0.45 | V3.0 + (code d'instance refactorisé RN) |
| v0.46 | V4.0 + (RN Code de chargeur de bundle refactorisé JS) |
| V0.46-V0.53 | v5.1 + (RN supprimé l'enregistrement inutilisé des modules JS) |
| V0.54-V0.55 | V5.3 + (Android Gradle Plugin 3.x Intégration) |
| V0.56-V0.58 | v5.4 + (versions améliorées RN pour les outils Android) |
| V0.59 | V5.6 + (Code de chargeur de bundle RN refactorisé) |
| V0.60-V0.61 | V6.0 + (RN a migré vers la mise à feu) |
| V0.62-V0.64 | v6.2 + (RN supprimé LiveleLoad) |
| V0.65-V0.70 | v7.0 + (RN à la mise à jour de la version iPhone-cible) |
| V0.71 | V8.0 + (RN a déménagé pour réagir-Native-Gradle-Plugin) |
Remarque: les versions react-native-code-push inférieures à V5.7.0 cesseront de travailler dans un avenir proche. Vous pouvez trouver plus d'informations dans notre documentation.
Nous travaillons dur pour répondre aux nouvelles versions de RN, mais elles nous cassent occasionnellement. Nous mettrons à jour ce graphique à chaque version RN, afin que les utilisateurs puissent vérifier pour voir notre support "officiel".
Lorsque vous utilisez le système React Native Assets (c'est-à-dire à l'aide de la syntaxe require("./foo.png") ), la liste suivante représente l'ensemble des composants (et accessoires) de base qui prennent en charge leurs images et vidéos référencées mises à jour via CodePush:
| Composant | Accessoire (s) |
|---|---|
Image | source |
MapView.Marker(Nécessite des maps réactifs >=O.3.2 ) | image |
ProgressViewIOS | progressImage , trackImage |
TabBarIOS.Item | icon , selectedIcon |
ToolbarAndroid(React natif 0,21.0+) | actions[].icon , logo , overflowIcon |
Video | source |
La liste suivante représente l'ensemble des composants (et des accessoires) qui ne prennent pas actuellement en charge leurs actifs via Codepush, en raison de leur dépendance sur les images et vidéos statiques (c'est-à-dire en utilisant la syntaxe { uri: "foo" } ):
| Composant | Accessoire (s) |
|---|---|
SliderIOS | maximumTrackImage , minimumTrackImage , thumbImage , trackImage |
Video | source |
Au fur et à mesure que les nouveaux composants principaux sont publiés, qui prennent en charge les actifs de référence, nous mettrons à jour cette liste pour garantir que les utilisateurs savent exactement ce qu'ils peuvent s'attendre à mettre à jour à l'aide de CodePush.
Remarque: CodePush ne fonctionne qu'avec des composants vidéo lors de l'utilisation require dans la source source. Par exemple:
< Video source = { require ( "./foo.mp4" ) } / > Une fois que vous avez suivi les instructions "de démarrage" à usage général pour configurer votre compte CodePush, vous pouvez démarrer votre application REACT Native REACT en exécutant la commande suivante à partir du répertoire racine de votre application:
npm install --save react-native-code-pushComme pour tous les autres plugins natifs React, l'expérience d'intégration est différente pour iOS et Android, donc effectuez les étapes de configuration suivantes en fonction de la plate-forme que vous ciblez. Remarque, si vous ciblez les deux plates-formes, il est recommandé de créer des applications Codepush distinctes pour chaque plate-forme.
Si vous souhaitez voir comment d'autres projets se sont intégrés à CodePush, vous pouvez consulter l'excellent exemple d'applications fournies par la communauté. De plus, si vous souhaitez vous familiariser rapidement avec Codepush + React Native, vous pouvez consulter les vidéos de démarrage impressionnantes produites par Bilal Budhani et / ou Deepak Sisodiya.
Remarque: Ce guide suppose que vous avez utilisé la commande react-native init pour initialiser votre projet Native React. Depuis mars 2017, la commande create-react-native-app peut également être utilisée pour initialiser un projet natif React. Si vous utilisez cette commande, veuillez exécuter npm run eject dans le répertoire domestique de votre projet pour obtenir un projet très similaire à ce que react-native init aurait créé.
Puis continuez à installer le module natif
Avec le plugin Codepush téléchargé et lié, et votre application demandant à Codepush d'où obtenir le bon pack JS, la seule chose qui reste est d'ajouter le code nécessaire à votre application pour contrôler les politiques suivantes:
Quand (et à quelle fréquence) pour vérifier une mise à jour? (Par exemple, démarrez l'application, en réponse à cliquer sur un bouton dans une page de paramètres, périodiquement à un intervalle fixe)
Lorsqu'une mise à jour est disponible, comment la présenter à l'utilisateur final?
La façon la plus simple de le faire est de "Codepush-ify" le composant racine de votre application. Pour ce faire, vous pouvez choisir l'une des deux options suivantes:
Option 1: enveloppez votre composant racine avec le composant d'ordre supérieur codePush :
Pour la composante de classe
import codePush from "react-native-code-push" ;
class MyApp extends Component {
}
MyApp = codePush ( MyApp ) ;Pour la composante fonctionnelle
import codePush from "react-native-code-push" ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( MyApp ) ;Option 2: Utilisez la syntaxe du décorateur ES7:
Remarque: les décorateurs ne sont pas encore pris en charge dans la mise à jour de la proposition en attente de Babel 6.x. Vous devrez peut-être l'activer en installant et en utilisant Babel-Preset-React-natif-stade-0.
Pour la composante de classe
import codePush from "react-native-code-push" ;
@ codePush
class MyApp extends Component {
}Pour la composante fonctionnelle
import codePush from "react-native-code-push" ;
const MyApp : ( ) => React$Node = ( ) => {
}
export default codePush ( MyApp ) ;Par défaut, CodePush vérifiera les mises à jour sur chaque démarrage de l'application. Si une mise à jour est disponible, elle sera téléchargée en silence et installée la prochaine fois que l'application sera redémarrée (soit explicitement par l'utilisateur final ou par le système d'exploitation), ce qui assure la moins d'invasive pour vos utilisateurs finaux. Si une mise à jour disponible est obligatoire, elle sera installée immédiatement, garantissant que l'utilisateur final l'obtient dès que possible.
Si vous souhaitez que votre application découvre des mises à jour plus rapidement, vous pouvez également choisir de vous synchroniser avec le serveur Codepush chaque fois que l'application reprend à l'arrière-plan.
Pour la composante de classe
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
class MyApp extends Component {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ;Pour la composante fonctionnelle
let codePushOptions = { checkFrequency : codePush . CheckFrequency . ON_APP_RESUME } ;
let MyApp : ( ) => React$Node = ( ) => {
}
MyApp = codePush ( codePushOptions ) ( MyApp ) ; Alternativement, si vous souhaitez un contrôle à grains fins lorsque la vérification se produit (comme un bouton appuyer sur un intervalle de minuterie), vous pouvez appeler CodePush.sync() à tout moment avec les SyncOptions souhaitées et désactiver éventuellement la vérification automatique de Codepush en spécifiant un Manuel 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 ) ; Si vous souhaitez afficher une boîte de dialogue de confirmation de mise à jour (une "installation active"), configurer lorsqu'une mise à jour disponible est installée (comme forcer un redémarrage immédiat) ou personnaliser l'expérience de mise à jour de toute autre manière, reportez-vous à la référence de l'API codePush() Pour plus d'informations sur la façon de modifier ce comportement par défaut.
Remarque: Si vous utilisez Redux et Redux Saga, vous pouvez alternativement à utiliser le module React-Native-Code-push-saga, qui vous permet de personnaliser lorsque sync est appelée d'une manière peut-être plus simple / plus idiomatique.
Android Google Play et iOS App Store ont des directives correspondantes qui ont des règles que vous devez connaître avant d'intégrer la solution Codepush au sein de votre application.
Le troisième paragraphe du sujet de l'abus de l'appareil et du réseau décrit que la mise à jour du code source par n'importe quelle méthode autre que le mécanisme de mise à jour de Google Play est limitée. Mais cette restriction ne s'applique pas à la mise à jour des faisceaux JavaScript.
Cette restriction ne s'applique pas au code qui s'exécute dans une machine virtuelle et a un accès limité aux API Android (tels que JavaScript dans un webview ou un navigateur).
Cela permet entièrement CodePush car il met à jour uniquement JS Bundles et ne peut pas mettre à jour la pièce de code native.
Le paragraphe 3.3.2 , car en 2015, le contrat de licence du programme Apple Developer Program a permis de réaliser des mises à jour en direct de JavaScript et d'actifs - et dans sa dernière version (20170605) téléchargeable ici cette décision est encore plus large:
Le code interprété peut être téléchargé sur une application, mais seulement si longtemps comme tel code: (a) ne modifie pas l'objectif principal de l'application en fournissant des fonctionnalités ou des fonctionnalités incompatibles avec l'objectif prévu et annoncé de la demande telle que soumise à l'application Store, (b) ne crée pas de magasin ou de vitrine pour d'autres code ou applications, et (c) ne contourne pas la signature, le bac à sable ou d'autres fonctionnalités de sécurité du système d'exploitation.
CodePush vous permet de suivre ces règles en pleine conformité tant que la mise à jour que vous poussez ne décolle pas de manière significative votre produit de son intention approuvée par l'App Store d'origine.
Pour rester plus en conformité avec les directives d'Apple, nous suggérons que les applications distribuées par l'App Store n'activent pas l'option updateDialog lors de l'appel de sync , car dans les directives de révision de l'App Store, il est écrit que:
Les applications ne doivent pas forcer les utilisateurs à évaluer l'application, à consulter l'application, à télécharger d'autres applications ou à d'autres actions similaires afin d'accéder aux fonctionnalités, au contenu ou à l'utilisation de l'application.
Ce n'est pas nécessairement le cas pour updateDialog , car il ne forcera pas l'utilisateur à télécharger la nouvelle version, mais au moins vous devriez être conscient de cette décision si vous décidez de le montrer.
Une fois votre application configurée et distribuée à vos utilisateurs, et que vous avez effectué des modifications JS ou des actifs, il est temps de les libérer. La façon recommandée de les libérer est d'utiliser la commande release-react dans l'application Center CLI, qui regroupera vos fichiers JavaScript, vos fichiers d'actifs et publiera la mise à jour du serveur Codepush.
Remarque: Avant de commencer à publier des mises à jour, veuillez vous connecter à App Center en exécutant la commande appcenter login .
Dans sa forme la plus élémentaire, cette commande ne nécessite qu'un seul paramètre: le nom de votre propriétaire + "/" + nom de l'application.
appcenter codepush release-react -a < ownerName > / < appName >
appcenter codepush release-react -a < ownerName > /MyApp-iOS
appcenter codepush release-react -a < ownerName > /MyApp-Android La commande release-react permet un flux de travail aussi simple car il fournit de nombreuses valeurs par défaut sensibles (comme la génération d'un bundle de libération, en supposant que le fichier d'entrée de votre application sur iOS est index.ios.js ou index.js ). Cependant, tous ces défauts peuvent être personnalisés pour permettre une flexibilité incrémentielle si nécessaire, ce qui en fait un bon ajustement pour la plupart des scénarios.
# 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 "
Le client Codepush prend en charge les mises à jour différentielles, donc même si vous publiez votre bundle et actifs JS à chaque mise à jour, vos utilisateurs finaux ne téléchargeront que les fichiers dont ils ont besoin. Le service le gère automatiquement afin que vous puissiez vous concentrer sur la création d'applications impressionnantes et nous pouvons nous soucier d'optimiser les téléchargements des utilisateurs finaux.
Pour plus de détails sur le fonctionnement de la commande release-react , ainsi que les différents paramètres qu'il expose, reportez-vous aux documents CLI. De plus, si vous préférez gérer l'exécution de la commande react-native bundle vous-même et, par conséquent, voulez une solution encore plus flexible que release-react , reportez-vous à la commande release pour plus de détails.
Si vous rencontrez des problèmes ou que vous avez des questions / commentaires / commentaires, vous pouvez nous cingler dans la chaîne de code-push # sur Reactiflux, nous envoyer un e-mail et / ou consulter les détails de dépannage ci-dessous.
Remarque: les mises à jour Codepush doivent être testées en modes autres que le mode de débogage. En mode de débogage, React Native Applowe toujours JS Bundle généré par Packager, donc JS Bundle téléchargé par CodePush ne s'applique pas.
Dans nos documents de démarrage, nous avons illustré comment configurer le plugin CodePush à l'aide d'une touche de déploiement spécifique. Cependant, afin de tester efficacement vos sorties, il est essentiel que vous tituriez des déploiements Staging et Production qui sont générés automatiquement lorsque vous avez créé votre application Codepush (ou tout déploiement personnalisé que vous avez peut-être créé). De cette façon, vous ne publiez jamais de mise à jour de vos utilisateurs finaux que vous n'avez pas pu vous valider.
Remarque: Notre fonctionnalité en arrière côté client peut aider à débloquer les utilisateurs après l'installation d'une version qui a abouti à un crash, et les rétroviseurs côté serveur (c.-à-d appcenter codepush rollback ) vous permettent d'empêcher les utilisateurs supplémentaires d'installer une mauvaise version une fois qu'il a été identifié. Cependant, c'est évidemment mieux si vous pouvez empêcher une mise à jour erronée d'être largement publiée en premier lieu.
Profiter des déploiements Staging et Production vous permet de réaliser un flux de travail comme celui qui suit (n'hésitez pas à personnaliser!):
Libérez une mise à jour Codepush vers votre déploiement Staging à l'aide de la commande appcenter codepush release-react (ou appcenter codepush release si vous avez besoin de plus de contrôle)
Exécutez votre création de stadification / bêta de votre application, synchroniser la mise à jour du serveur et vérifier qu'elle fonctionne comme prévu
Promouvoir la version testée de Staging à Production à l'aide de la commande appcenter codepush promote
Exécutez votre génération de production / version de votre application, synchroniser la mise à jour du serveur et vérifier qu'elle fonctionne comme prévu
Remarque: Si vous souhaitez adopter une approche plus prudente, vous pouvez même choisir d'effectuer un "déploiement mis en scène" dans le cadre du n ° 3, ce qui vous permet d'atténuer le risque potentiel supplémentaire avec la mise à jour (comme vos tests dans le # 2 Touch All Appareils / conditions possibles?) En mettant uniquement la mise à jour de la production à la disposition d'un pourcentage de vos utilisateurs (par exemple appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20 ). Ensuite, après avoir attendu un temps raisonnable pour voir si des rapports de crash ou des commentaires des clients entrent en jeu, vous pouvez l'étendre à l'ensemble de votre public en exécutant appcenter codepush patch -a <ownerName>/<appName> Production -r 100 .
Vous remarquerez que les étapes ci-dessus se réfèrent à une "build de mise en scène" et à une "construction de production" de votre application. Si votre processus de génération génère déjà des binaires distincts par "environnement", vous n'avez pas besoin de lire plus loin, car l'échanger des clés de déploiement de codepush est comme gérer la configuration spécifique à l'environnement pour tout autre service que votre application utilise (comme Facebook). Cependant, si vous recherchez des exemples ( y compris des projets de démonstration ) sur la façon de configurer votre processus de construction pour s'adapter à cela, reportez-vous aux sections suivantes, selon la ou les plateformes que votre application cible:
La section ci-dessus a illustré comment vous pouvez tirer parti de plusieurs déploiements de codepush afin de tester efficacement vos mises à jour avant de les remettre largement à vos utilisateurs finaux. Cependant, puisque ce flux de travail intègre statiquement l'affectation de déploiement dans le binaire réel, une création de stadification ou de production ne synchronisera jamais que les mises à jour à partir de ce déploiement. Dans de nombreux cas, cela est suffisant, car vous ne voulez que votre équipe, vos clients, les parties prenantes, etc. Cependant, si vous souhaitez pouvoir effectuer des tests A / B ou fournir un accès précoce à votre application à certains utilisateurs, il peut s'avérer très utile pour pouvoir placer dynamiquement des utilisateurs (ou un public) spécifiques en déploiements spécifiques lors de l'exécution.
Afin d'atteindre ce type de workflow, tout ce que vous avez à faire est de spécifier la clé de déploiement que vous souhaitez que l'utilisateur actuel se synchronise lors de l'appel de la méthode codePush . Lorsqu'il est spécifié, cette clé remplacera la "par défaut" qui a été fournie dans les fichiers Info.plist (iOS) de votre application ou MainActivity.java (Android). Cela vous permet de produire une construction pour la mise en scène ou la production, qui est également capable d'être "redirigé" dynamiquement au besoin.
// 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 } ) ;Avec ce changement en place, il s'agit maintenant de choisir comment votre application détermine la bonne clé de déploiement pour l'utilisateur actuel. En pratique, il existe généralement deux solutions pour cela:
Exposez un mécanisme visible utilisateur pour changer les déploiements à tout moment. Par exemple, votre page Paramètres pourrait avoir une bascule pour activer l'accès "bêta". Ce modèle fonctionne bien si vous n'êtes pas préoccupé par la confidentialité de vos mises à jour de pré-production, et que vous avez des utilisateurs puissants qui peuvent vouloir opter pour les mises à jour antérieures (et potentiellement buggy) à leur propre volonté (un peu comme les canaux chromés ). Cependant, cette solution met la décision entre les mains de vos utilisateurs, ce qui ne vous aide pas à effectuer des tests A / B de manière transparente.
Annotez le profil côté serveur de vos utilisateurs avec un morceau de métadonnées supplémentaire qui indique le déploiement avec lequel ils devraient se synchroniser. Par défaut, votre application peut simplement utiliser la clé binaire endettée, mais une fois qu'un utilisateur s'est authentifié, votre serveur peut choisir de les "rediriger" vers un autre déploiement, ce qui vous permet de placer progressivement certains utilisateurs ou groupes dans différents déploiements au besoin selon les besoins . Vous pouvez même choisir de stocker le serveur-réponse dans le stockage local afin qu'il devienne le nouveau défaut. La façon dont vous stockez la clé aux côtés des profils de votre utilisateur est entièrement à la hauteur de votre solution d'authentification (par exemple Auth0, Firebase, API DB + REST personnalisée), mais est généralement assez trivial à faire.
Remarque: Si nécessaire, vous pouvez également implémenter une solution hybride qui a permis à vos utilisateurs finaux de basculer entre différents déploiements, tout en permettant à votre serveur de remplacer cette décision. De cette façon, vous avez une hiérarchie de "résolution de déploiement" qui garantit que votre application a la possibilité de se mettre à jour à l'extérieur, vos utilisateurs finaux peuvent se sentir récompensés en obtenant un accès précoce aux bits, mais vous avez également la possibilité de Exécutez les tests A / B sur vos utilisateurs au besoin.
Étant donné que nous vous recommandons d'utiliser le déploiement Staging pour les tests de pré-libération de vos mises à jour (comme expliqué dans la section précédente), il n'est pas nécessaire de l'utiliser pour effectuer des tests A / B sur vos utilisateurs, au lieu d'autoriser le début Accès (comme expliqué dans l'option n ° 1 ci-dessus). Par conséquent, nous vous recommandons d'utiliser pleinement les déploiements d'applications personnalisés, afin que vous puissiez segmenter vos utilisateurs, mais c'est logique pour vos besoins. Par exemple, vous pouvez créer des déploiements à long terme ou même ponctuels, publier une variante de votre application, puis y placer certains utilisateurs afin de voir comment ils s'engagent.
// #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 Remarque: Le nombre total d'utilisateurs qui est signalé dans les «métriques d'installation» de votre déploiement prendra en compte les utilisateurs qui ont «passé» d'un déploiement à un autre. Par exemple, si votre déploiement Production rapporte actuellement 1 utilisateur total, mais que vous passez dynamiquement cet utilisateur à Staging , le déploiement Production rapporterait 0 utilisateurs totaux, tandis que Staging rapporterait 1 (l'utilisateur qui vient de commuter). Ce comportement vous permet de suivre avec précision l'adoption de votre version, même en cas d'utilisation d'une solution de redirection de déploiement basée sur l'exécution.
La communauté indigène React a gracieusement créé des applications open source impressionnantes qui peuvent servir d'exemples pour les développeurs qui commencent. Ce qui suit est une liste des applications natives OSS React qui utilisent également CodePush, et peuvent donc être utilisées pour voir comment les autres utilisent le service:
De plus, si vous cherchez à commencer avec React Native + Codepush et que vous cherchez un kit de démarrage génial, vous devriez consulter ce qui suit:
Remarque: Si vous avez développé une application Native React à l'aide de CodePush, c'est également open-source, veuillez nous le faire savoir. Nous serions ravis de l'ajouter à cette liste!
La méthode sync comprend beaucoup de journalisation diagnostique prêt à l'emploi, donc si vous rencontrez un problème lorsque vous l'utilisez, la meilleure chose à essayer est d'examiner les journaux de sortie de votre application. Cela vous indiquera si l'application est configurée correctement (comme le plugin peut-il trouver votre clé de déploiement?), Si l'application est en mesure d'atteindre le serveur, si une mise à jour disponible est découverte, si la mise à jour est téléchargée / installée avec succès, etc. Nous voulons continuer à améliorer la journalisation aussi intuitive / complète que possible, alors faites-nous savoir si vous le trouvez déroutant ou manquant quoi que ce soit.
La façon la plus simple de visualiser ces journaux consiste à ajouter l'indicateur --debug pour chaque commande. Cela sortira un flux de journal filtré sur des messages Codepush. Cela facilite l'identification des problèmes, sans avoir besoin d'utiliser un outil spécifique à la plate-forme ou de parcourir un volume potentiellement élevé de journaux.
De plus, vous pouvez également utiliser l'un des outils spécifiques à la plate-forme pour afficher les journaux Codepush, si vous êtes plus à l'aise avec eux. Démarrage simple de la console Chrome Devtools, de la console Xcode (IOS), de la console OS X (IOS) et / ou du logcat ADB (Android), et recherchez des messages qui sont préfixés avec [CodePush] .
Notez que par défaut, les journaux natifs React sont désactivés sur iOS dans les versions de version, donc si vous souhaitez les afficher dans une version de version, vous devez apporter les modifications suivantes dans votre fichier AppDelegate.m :
Ajoutez une instruction #import <React/RCTLog.h> . Pour RN <v0.40 Utilisation: #import "RCTLog.h"
Ajoutez l'instruction suivante en haut de votre application:didFinishLaunchingWithOptions Méthode:
RCTSetLogThreshold (RCTLogLevelInfo);Vous pourrez maintenant voir les journaux CodePush en mode débogage ou libération, sur iOS ou Android. Si l'examen des journaux ne fournit pas d'indication du problème, veuillez vous référer aux problèmes communs suivants pour des idées de résolution supplémentaires:
| Problème / symptôme | Solution possible |
|---|---|
| Erreur de compilation | Vérifiez que votre version de React Native est compatible avec la version Codepush que vous utilisez. |
Timeout / hangage du réseau lors de l'appel sync ou checkForUpdate dans le simulateur iOS | Essayez de réinitialiser le simulateur en sélectionnant le Simulator -> Reset Content and Settings.. Élément de menu, puis relancez votre application. |
Le serveur répond avec un 404 lors de l'appel sync ou checkForUpdate | Vérifiez la clé de déploiement que vous avez ajoutée à votre Info.plist (iOS), build.gradle (Android) ou que vous passez à sync / checkForUpdate , est en fait correct. Vous pouvez exécuter appcenter codepush deployment list <ownerName>/<appName> --displayKeys pour afficher les touches correctes pour vos déploiements d'applications. |
| Mise à jour sans être découverte | Vérifiez que la version de votre application en cours d'exécution (comme 1.0.0 ) correspond à la version que vous avez spécifiée lors de la publication de la mise à jour vers CodePush. De plus, assurez-vous que vous publiez le même déploiement avec lequel votre application est configurée avec qui vous synchroniser. |
| Mise à jour sans être affichée après le redémarrage | Si vous n'appelez pas sync sur le démarrage de l'application (comme dans componentDidMount de votre composant racine), vous devez appeler explicitement notifyApplicationReady sur l'application Start, sinon, le plugin pensera que votre mise à jour a échoué et le faire reculer. |
| J'ai publié une mise à jour pour iOS, mais mon application Android montre également une mise à jour et elle la brise | Assurez-vous d'avoir différentes clés de déploiement pour chaque plate-forme afin de recevoir correctement les mises à jour |
| J'ai publié une nouvelle mise à jour mais les modifications ne sont pas reflétées | Assurez-vous que vous exécutez l'application dans des modes autres que le débogage. En mode de débogage, React Native Applowe toujours JS Bundle généré par Packager, donc JS Bundle téléchargé par CodePush ne s'applique pas. |
| Aucun bundle JS n'est trouvé lors de l'exécution de votre application contre le simulateur iOS | Par défaut, React Native ne génère pas votre bundle JS lors de la course contre le simulateur. Par conséquent, si vous utilisez [CodePush bundleURL] et que vous ciblez le simulateur iOS, vous obtenez peut-être un résultat nil . Ce problème sera résolu dans RN 0,22,0, mais uniquement pour les versions de libération. Vous pouvez débloquer ce scénario dès maintenant en effectuant ce changement localement. |
En plus de pouvoir utiliser la CLI Codepush pour publier "manuellement" des mises à jour, nous pensons qu'il est important de créer une solution reproductible et durable pour fournir des mises à jour contenus à votre application. De cette façon, il est assez simple pour vous et / ou votre équipe de créer et de maintenir le rythme de l'exécution de déploiements agiles. Afin d'aider à la configuration d'un pipeline de CD basé sur Codepush, reportez-vous aux intégrations suivantes avec divers serveurs CI:
De plus, si vous souhaitez plus de détails sur ce à quoi peut ressembler un flux de travail mobile CI / CD mobile, qui comprend Codepush, consultez cet excellent article de l'équipe d'ingénierie de Zeemee.
Ce module expédie son fichier *.d.ts dans le cadre de son package NPM, qui vous permet de simplement l' import et de recevoir Intellisense dans les éditeurs de prise en charge (comme le code Visual Studio), ainsi que la vérification du type de compilation si vous êtes Utilisation de TypeScript. Pour la plupart, ce comportement devrait simplement fonctionner hors de la boîte, cependant, si vous avez spécifié es6 comme valeur pour l'option target ou compilateur module dans votre fichier tsconfig.json , alors assurez-vous que vous définissez également Option moduleResolution au node . Cela garantit que le compilateur TypeScript examinera dans le node_modules pour les définitions de type des modules importés. Sinon, vous obtiendrez une erreur comme celle suivante lorsque vous essayez d'importer le module react-native-code-push : error TS2307: Cannot find module 'react-native-code-push' .
Ce projet a adopté le code de conduite open source Microsoft. Pour plus d'informations, consultez le code de conduite FAQ ou contactez [email protected] avec toute question ou commentaire supplémentaire.
