Introduction

React Native utilise du JS pour piloter le rendu des moteurs graphique d'IOS et d'Android, cette spécificité permet de se passer de compilation de code natif sous certaines conditions, c'est une des grandes forces de l'outil.

Tant que le code natif n'est pas modifié (ajout de nouvelles librairies natives ou mise à jours de ces dernières), on peut effectuer des mises à jours à la volée par le réseau.

Mise à part cela, en ce qui concerne donc les procédés de déploiements et d'intégration continue, nous sommes sensiblement sur les même problématiques que les développeurs natifs.

Une application React native étant une vrai application native.

Quelles spécificités pour quelle plateforme ?

Pour IOS, nous avons besoin d'un couple de certificats et de fichiers permettant de signer l'application en vu d'une installation sur un vrai terminal mobile. C'est ce que l'on appelle un profil de provision ou « provisionning profile » (PP) en anglais.

Un PP est l'assemblage d'un ou plusieurs certificats de développeurs, d'un certificat d'application (qui est lié à un identifiant d'application) et éventuellement d'une liste d'identifiants de terminaux sur lesquels l'application pourra être installée en dehors de l'app store officiel.

Pour pouvoir créer une archive IOS exécutable .IPA pour un terminal Apple, il vous utiliser un Mac, pour votre CI pensez donc à avoir cet outil chez vous ou bien vous pouvez en louer un à la demande chez https://www.macstadium.com/ moyennant finance ou prochainement grâce à Github Actions.

Pour Android,  le procédé est plus simple et ne nécessitera qu'une machine possédant Java, ce qui simplifie largement le procédé de build qui peut être délégué à des services cloud type EC2 ou Compute Engine qui s'allumeront à la demande pour la tâche et s'éteindront aussitôt une fois cette dernière accomplie.

Les applications Android sont quant à elles signées via une clé unique, vérifiée par le Play Store à chaque nouvelle mise à jour afin de certifier la provenance du paquet applicatif.

Sachez également que vous pouvez déléguer vos temps de builds à divers services tiers tel que Microsoft Appcenter Build ou encore Bitrise qui lui va encore plus loin.

Voilà pour les contraintes liées à chaque plateforme. Mais comment bien gérer ses environnement et le déploiements de nouvelles versions de paquets applicatifs ?

Comment gérer ses environnements de tests clients ?

Plusieurs solutions s'offrent à nous mais je recommande d'utiliser la solution Microsoft AppCenter (anciennement HockeyApp).

Cette outil permet de déployer des paquets applicatifs que l'on va ensuite partager avec une audience via une page contenant un QR code auto-généré par la plateforme. En scannant ce dernier l'utilisateur pourra télécharger la version de l'application déposée.

De cette manière, on peut parfaitement imaginer définir un groupe d'utilisateur nommé beta-testeurs qui aura accès à ces archives téléchargées par les développeurs, afin de tester les modifications et nouvelles fonctionnalités d'une livraison.

Le service appcenter réponds parfaitement au contraintes d'un environnement de tests utilisateur.

  1. Tests privés accessibles à un groupe restreint de personnes.
  2. Rapidité de livraison des modifications. (Déploiement continue)
  3. Facilité de téléchargement et historique des livraisons.

Dans un second temps et pour réaliser des « open beta », on peut utiliser les services respectifs des stores applicatifs pour partager des paquets applicatifs.

Pour IOS et Apple ce service s'appelle Testflight mais nécessite une pré-validation d'Apple pouvant prendre quelques jours.

Pour Android Google play propose un service de déploiement Alpha et Beta, moins contraignant que chez son homologue la pomme.

Tester les livraisons

Afin de livrer un produit de qualité, qui ne régresse pas à chaque déploiement et dans l'optique de sécuriser le périmètre du produit, il est très intéressant de mettre en place des tests automatisés.

Pour tester les nouvelles versions de notre paquet applicatif, plusieurs choses sont possibles :

Des tests « end-to-end » (e2e), soit des tests effectués sur de vrai terminaux mobile et/ou des émulateurs. Le bénéfice étant d'être au plus proche de l'expérience finale utilisateurs pour tester.

On pourra alors utiliser des framework comme Detox (créé par Wix) ou Appium, présentant chacun ses propres spécificités et contraintes. Or de manière globale on sent qu'aujourd'hui ces produits ne sont pas encore adaptés au testing d'applications React native avec un code de tests unique pour les deux plateformes. Cependant je vous invite à essayer les deux solutions qui sont très abordable en terme de prise en main dans l'attente d'un meilleur support.

Une autre solution sont les tests de composants et unitaires, qui pourront être réalisés par des outils comme Jest (un outil développé également par Facebook), notamment via les « Snapshot tests ».

Livrer en production

Selon la plateforme il faudra suivre les procédures respectives de chaque store (Apple App Store ou Google Play par exemple) et passer les différentes phases de revues applicative mise en place par les équipes en charge de vérifier les applications publiées.

Ces vérifications peuvent prendre jusqu'à 4 jours ouvrés selon les périodes, notamment sur l'Apple App Store.

Comme nous l'avons vu au début de cet article, une alternative très judicieuse est d'utiliser les mises à jours à la volée, par exemple le service Codepush de Microsoft qui permet de délivrer des mises à jours instantanées.

Cela permet de passer moins de temps pour livrer  un correctif en passant outre les procédés de validation des stores. Cela permet également par son fonctionnement de s'assurer qu'une mise à jour est livré sur tous les terminaux en même temps sans attendre que les gens fassent la mise à jour manuellement depuis leurs store respectif.

Le mot de la fin

Le déploiement et l'intégration continue pour une application React native ne diffère pas beaucoup de procédés standard des livraisons d'applications natives.

On pourra profiter d'outils permettant de factoriser nos tests automatisés des deux plateformes tel que le framework Detox créé par Wix. Mais surtout du gros avantage de déployer des mises à jours instantanées par le réseau, notamment via le service Codepush de Microsoft, ce qui nous rapproche grandement des avantages que nous offre une progressive webapp en gardant les performances d'une application native.