Julien Fournier - Tech Lead & Coordinateur d'agence
Découvrez notre calendrier de l'Avent spécial éco-conception
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
Title document
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
Concevoir une application mobile à la fois fiable et performante est un défi de taille pour les équipes technique. La marge d'erreur est inexistante. Un bug, une latence excessive et c'est le couperet : 62% des utilisateurs n'hésitent pas à désinstaller une application après le premier problème. Pire, la menace d'une critique négative sur les stores pèse lourd, capable d'entacher sérieusement la réputation de votre produit.
Face à cette exigence sans compromis, comment les équipes techniques peuvent-elles garantir la robustesse de leur produit ? Qu'est-ce qui distingue une application mobile acclamée par ses utilisateurs d'une autre condamnée à l'oubli dans la masse des applications des stores ?
Dans cet article, nous vous dévoilons une série de nos meilleures pratiques pour améliorer la fiabilité de votre application mobile en prenant le prisme de la technique. Fruits de nos nombreuses années d'expériences dans le domaine, elles couvrent un large spectre : des principes méthodologiques et organisationnels de base aux stratégies techniques plus avancées, telles que l'automatisation des tests end-to-end. Embarquez avec nous dans ce voyage vers l'excellence en matière d'application mobile.
À bien des égards la création de produits mobiles est un exercice complexe qui requiert une expertise particulière. Les défis sont multiples et les coûts, comparativement à un équivalent web, sont souvent plus élevés. Pourquoi ? Parce qu'à chaque étape de la réalisation : conception, développement, recette, déploiement et exploitation, il y a des particularités qui complexifient l'exercice. Nous ferons à de multiples reprises la comparaison avec le développement web classique (site web, applications web, SPA...), car la frontière entre les deux mondes s'atténue ces dernières années avec l'émergence de technologies qui floutent la frontière entre les deux mondes (ex: React vs React Native). Nous remarquons que les néophytes ont souvent tendance à penser de façon assez biaisée qu'une application mobile est un projet de moindre ampleur qu'un équivalent web car la cible de périphériques est d'apparence plus restreinte. C'est au final assez faux et c'est ce que nous allons développer.
La conception : un premier défi est la diversité des périphériques à prendre en compte. Le paysage du mobile est très varié, avec des résolutions d'écran, des ratios, des orientations, des densités de pixels qui changent constamment. Sur les performances en particulier, le fossé entre les téléphones Android d'entrée de gamme et les iPhones haut de gamme est particulièrement marqué. Manier quelques résolutions d'écrans pour du web responsive est bien plus simple. L'exigence en termes d'interface utilisateur est aussi moindre. Toujours en termes de conception, il faut aussi considérer les caractéristiques des mobiles. Les applications peuvent utiliser le Bluetooth, prendre des photos, permettre de la reconnaissance vocale, de l'authentification biométrique, et bien plus encore. Elles peuvent même intégrer des systèmes de paiement ultra simples comme Apple Pay ou accéder à des coffres-forts numériques pour stocker des données de santé. Tous ces paramètres doivent être pris en compte dès la conception avec la complexité qu'ils engendrent en termes de parcours utilisateurs qu'ils génèrent : parcours nominaux et parcours alternatifs. Nous constatons bien trop souvent une propension à ne pas s'ennuyer à concevoir le cas où l'utilisateur refuse d'autoriser telle permission. Malheureusement, ce défaut de conception aura comme conséquence directe des implémentations bancales de la part des développeurs qui "improviseront" ou se retrouveront bloqués.
Les complexités de développement : comme évoqué précédemment, les applications mobiles évoluent au sein de systèmes complexes : elles interagissent avec le monde réel d'une part grâce à leurs capteurs et au sein de leur propre écosystème logiciel d'autre part (avec leur système d'exploitation et les nombreuses fonctionnalités qu'il permet d'intégrer). In fine, toute la complexité qui existait déjà à l'étape de la conception se renforce à l'étape de l'implémentation. Ces interactions, bien que rendant les applications mobiles très utiles et qui sont d'ailleurs à l'origine de leur succès, sont également trop souvent à l'origine de défaillances. Les cas particuliers sont extrêmement nombreux et se croisent entre eux. Par exemple : il est beaucoup plus complexe d'implémenter une fonctionnalité qui dépend à la fois de la géolocalisation, Bluetooth et d'un SDK tiers que simplement l'un des 3 car il faudra être capable de gérer la combinatoire des cas spécifiques à chacune de ces briques.
La recette : le développement mobile est aussi différent de l'environnement du PC bureautique en ce qui concerne le processus de recette. L'interface utilisateur de l'individu en charge de la recette est extrêmement limitante. Lorsque l'on travaille sur un ordinateur, une souris et un clavier facilitent la description d'une anomalie via un commentaire écrit ou l'annotation d'une capture d'écran. Sur mobile, ces tâches sont plus complexes et il faudrait pour bien se restreindre à faire la recette dans de "bonnes conditions", c'est-à-dire avec un ordinateur à portée de main pour faire des remontées qualitatives. Malheureusement, le côté mobile faisant que, on constate que les parties prenantes auront tendance à faire la recette dans des conditions de mobilités... Le résultat ? Il est courant d'avoir des rapports de bug de mauvaise qualité dans le cas d'un développement mobile.
Autre difficulté liée à la recette : il est souvent compliqué de reproduire un problème. Dans le cas du développement web, nous sommes habitués à, de façon simpliste, faire un rechargement de la page accompagné de quelques interactions. Sur mobile ? Il faut bien souvent relancer l'application, potentiellement supprimer ses données locales, identifier le périphérique et l'OS concerné, refaire tout un tunnel de navigation qui pourra enfin permettre d'arriver sur la "vue" concernée par l'anomalie en question, pour enfin pouvoir effectuer les quelques interactions directement impliquées dans la génération de l'anomalie.
Les déploiements de versions de test : les mises à dispositions de versions (builds) de tests sont très, trop lentes sur mobiles. Encore une fois la comparaison avec le web est brutale, car le déploiement d'une version de test est généralement une affaire de minutes. La différence entre les 2 mondes ? La nécessite d'avoir une CI/CD capable de compiler un exécutable natif pour iOS et Android, opération nettement plus coûteuse que de générer un simple fichier JavaScript et quelques assets dans le cas d'une Single Page App. Cette durée de mise à disposition d'une version de test est encore plus mise à mal par les "App Stores", passage obligé (en particulier côté Apple) pour distribuer facilement un build à des populations non-initiées. Dès lors que l'on envoie un build sur les stores Apple et Google Play, des vérifications sur l'exécutable envoyé vont se dérouler, dans le but de vérifier que nous ne soumettez pas un virus par exemple. Elles aussi vont durer un certain temps (une trentaine de minutes en moyenne). Friction suivante : la gestion des groupes de diffusion à qui l'on pourra distribuer ces fameuses versions de test. Chaque "store" ayant ses propres particularités (vocabulaire et concepts), il faut bien en saisir le fonctionnement pour pouvoir en tirer parti. La recette est normalement organisée de sorte à ce que, les développeurs valident d'abord puis donnent leur go aux équipes de QA, Product Owner, puis à leur tour le donnent aux parties prenantes plus high level, telle que le Product Manager, le CPO/CEO. Bien souvent, parce que les équipes ont ajouté toutes les parties prenantes dans l'équipe de développeurs internes (façon de faire la plus simple), l'effet de bord qui suit est que l'organisation en peau d'oignon décrite précédemment s'en retrouve brisée car tous seront automatiquement notifiés dès la mise à disposition d'un nouveau build. Malheur à votre équipe technique si un build instable se retrouve un peu trop vite entre les mains de votre CEO qui attend avec impatience une fonctionnalité critique.
Le déploiement de versions publiques (a.k.a mises en production) : dernière étape de la réalisation d'une application mobile : sa diffusion officielle. Avant de pouvoir publier votre build, les App Stores (iOS / Android) imposent des processus de validation. Ces processus seront une fois de plus un élément qui ralentira la chaîne globale. Le moindre correctif ne peut être mis à disposition de vos utilisateurs en moins de quelques heures. C'est un incompressible. À cette étape des vérifications finales, votre build peut être également refusé par les équipes de validation des stores. Parfois pour une simple icône manquante, parfois pour des raisons autrement plus structurantes, comme une fonctionnalité incompatible avec les politiques des stores. Annoncer lorsque l'attente est au plus haut et après une phase de recette intensive que l'application a été invalidée est un véritable revers pour votre équipe technique qui apparaîtra vite comme incompétente.
La plateforme de développement : enfin, nous constatons que la logique d'App Store (iOS & Android) influence les pratiques de développement, parfois pour le pire. Elle peut induire des pratiques absurdes. Dans le développement web "classique", il est usuel de proposer un environnement de test, un autre de production. Il n'est pas rare d'en voir davantage, comme des environnements de pré-production. Sur le mobile, en ne déclarant qu'une seule application dans les stores, les développeurs ne disposent en réalité que d'un unique environnement de production et nous aurons l'occasion d'en reparler plus tard. En-tout-cas, rien ne pousse pourtant à n'avoir pour une seule base de code qu'une seule application distribuée...
La liste des spécificités propre au développement mobile est encore bien longue et il serait aisé de compléter les points précédents. Toutes ces spécificités font que la réalisation d'une application mobile est complexe et nécessite une vraie expertise pour assurer la fiabilité du produit et sa maintenabilité. Chaque anomalie, identifiée en phase de recette ou en production va fatiguer votre équipe technique, car les allers et retours seront lents, car il faudra tester des conditions multiples et croisées. Et malheureusement, d'expérience, la majorité des entreprises qui développent des applications mobiles disposent d'équipes techniques relativement limitées.
Alors, comment s'en sortir dans ce contexte difficile ? Face à ces enjeux, il est possible de mettre en place un certain nombre de garde-fous. D'abord vous devriez vous faire accompagner d'experts en la matière et nous sommes là pour vous aider. Ensuite des pratiques simples et efficaces permettront d'éviter certains écueils d'une part, c'est ce que nous verrons lors de la prochaine section. La mise en oeuvre de concepts techniques avancés permettront d'aller encore plus loin, c'est ce que nous aborderons dans une seconde partie. Mis bout à bout, ces changements devraient améliorer considérablement la qualité de vos livrables.
Il y a des approches qui auront un impact direct sur la qualité de vos produits mobiles. Un premier bon niveau d'action est de revoir son approche de la conception et du développement en prenant au plus tôt en compte les contraintes des stores. Ensuite, il faut revoir son approche de la recette en y intégrant un "sanity check". Enfin l'utilisation de multiples "bundle ID" pourra aussi éviter quelques erreurs aux conséquences graves.
Si vous êtes membre d'une équipe technique de développement mobile, vous devriez avoir lu les Review Guidelines des stores Google et Apple au moins une fois. Il ne s'agit pas de maîtriser sur le bout des doigts son contenu mais au moins de comprendre l'esprit de ce qui est permis et de ce qui ne l'est pas.
Il n'y a pas de perte d'énergie, de temps et d'argent plus bête que celle de développer entièrement une fonctionnalité qui sera refusée en bloc par les stores car non-conforme.
Ne faites pas l'impasse sur la lecture de ces guidelines. Faites en sorte que ces documents soient lus et connus de vos Lead Developpers, Product Owners ou Product Managers.
En particulier Apple a une idée bien précise de ce que peut ou ne peut pas faire une application. Ses revues sont particulièrement minutieuses et strictes. Par exemple, dans le cas d'une application nécessitant une authentification pour accéder aux fonctionnalités, Apple peut demander à ce que cette authentification saute et dispose d'un accès non authentifié (invité) de sorte à ce que vous permettiez aux utilisateurs de se servir de l'application sans avoir à vous communiquer leurs données. Ce cas est malheureusement commun et nous en avons déjà fait la malheureuse expérience.
Autre erreur de débutant : attendre d'avoir terminé complètement les développements pour soumettre l'application et s'apercevoir seulement à ce moment que l'application n'est pas conforme. Les demandes de changement réclamées par les stores sont parfois minimes : une icône de l'app manquante, un paramètre mal déclaré. Dans le meilleur des cas, pour ce type de problèmes mineurs, vous perdrez une journée en partant du principe que l'implémentation du correctif soit rapide et que les équipes de reviews des stores le soient tout autant. Il n'est pas réaliste d'espérer mieux.
Par contre, si des fondamentaux de votre application sont remis en cause, vous pouvez y perdre gros, comme nous l'avons déjà évoqué précédemment. Se faire retoquer pour une erreur de conception, cumulé à un calendrier de mise en production imminent peut être catastrophique en terme d'impact budget, délais, business...
Ce que tout le monde ne comprend pas toujours, en tout cas pas assez vite, c'est que soumettre une application pour qu'elle soit revue n'implique pas qu'elle sera ensuite visible sur les stores. Il n'y a donc pas de crainte à avoir à ce niveau-là. Autrement dit : faites des soumissions le plus tôt possible pour avoir rapidement un feedback, c'est-à-dire dès que des parcours essentiels commencent à être disponibles. Et répétez l'expérience souvent, à chaque nouvelle fonctionnalité terminée.
Le sanity check est l’ensemble des scénarios de tests qui permettent une vérification rapide des fonctions vitales d’une application. La loi des 20/80 s'applique au sanity check : ces tests qui constitueront 20% (voir moins !) de l'ensemble de vos scénarios de tests permettront d'éviter la majeure partie de vos régressions. Par exemple, un "sanity check" très simple serait de s'assurer que les utilisateurs arrivent à se connecter à votre application et que les écrans principaux se chargent correctement.
Lorsque l'on connaît bien son application et son équipe technique, formaliser des sanity check efficaces peut permettre d'accélérer très fortement votre recette.
Nous pensons que chaque application doit disposer de scénarios de tests dits de "sanity check" et nous recommandons de doser la complexité de ces scénarios pour que la passe puisse être faite en 1 heure tout compris (plateformes, scénarios, OS...). Enfin, nous recommandons également une passe avant chaque soumission sur les stores.
Dans le développement web, il est courant d'avoir des environnements de tests distincts de ceux de production. On les appelle souvent environnement de recette, staging, dev ou pre-production. Paradoxalement, dans le développement mobile, nous sommes encouragés à ne proposer qu'une seule application, identifiée techniquement par son bundle ID, unique.
Pour imiter cette notion d'environnement, nous avons constaté une créativité certaine de la part des développeurs pour contourner la limitation de l'application unique (et donc de l'environnement unique). Nous avons vu des modes secrets implémentés, permettant selon des combinaisons de gestes de pouvoir accéder à des menus cachés, eux-même donnant la capacité de changer l'URL d'une API distante. Nous avons vu des pratiques plus hasardeuses, consistant à produire selon le besoin un build connecté au backend de production sinon à celui de test. Malheureusement, nous avons aussi vu l'un de ces builds connectés au backend de test, être publié par erreur (catastrophe !).
Au final, la façon la plus fiable que nous connaissons pour résoudre ce problème consiste à avoir autant "bundle ID", autrement dit plusieurs apps. Chaque "bundle ID" devient ainsi l'équivalent d'un environnement. Dans cette configuration, la probabilité de pousser par erreur un build mal configuré devient quasi nulle. Cette approche permet aussi d'avoir plusieurs versions d'une même application installée en même temps sur votre mobile, ce qui évite des désinstallations (suivies de pertes de sessions etc.) intempestives selon l'environnement du build. C'est l'une des approches mises en avant par Expo. Elle comporte néanmoins le défaut de devoir pour certains fournisseurs (ex: Firebase) de devoir dupliquer l'environnement, car spécifique à un bundle ID. La mise en place d'une telle approche nécessite d'être à l'aise avec la configuration des stores, la gestion des certificats et des process de build.
Une approche intermédiaire (ou complémentaire) peut être d'utiliser des jeux d'icônes différentes pour une même application (donc un même bundle ID) selon qu'elle soit connectée à votre environnement de staging ou production.
Il est encore possible d'aller plus loin en mettant en place ce que nous appelons une Mobile Product Factory : une CI/CD spécialement bien configurée pour les applications mobiles avec l'emploi de techniques particulières telles l'automatisation des tests, les Device Farm et le contournement de leur limitations.
La pyramide de test est le fait d'ordonnancer correctement le déroulement de tests (automatisé pour la plupart) de sorte à permettre la détection de défauts le plus tôt possible. Dans le contexte du développement mobile cette approche de l'exécution des temps est d'autant plus importante que les builds peuvent être particulièrement longs : lorsqu'on est nombreux à se partager une même CI/CD, on ne veut pas en pénaliser d'autres ni attendre soit même durant de long moment d'attente.
Nous avons pour habitude de déployer 5 grands types de tests sur nos projets d'applications mobiles :
L’idée générale derrière ces types de tests, dont certains sont manuels et d’autres sont automatiques, est donc de les exécuter séquentiellement en allant des plus rapides à exécuter et moins couteux à mettre en oeuvre, aux plus lents et plus couteux : c'est notre fameuse pyramide de tests. La respecter dans le contexte de l'environnement mobile est d'autant plus intéressant que nous l'avons vu plus tôt : toutes les opérations de build sont affreusement lentes et il faut à tout prix conserver un maximum de réactivité.
Dans le cas d'un développement mobile, nous conseillons l'approche minimale suivante, que nous jugeons suffisamment pragmatique :
Nous préconisons de les déclencher à chaque commit lorsqu'une Pull-Request est ouverte ou à défaut à chaque commit sur vos branches principales.
Les tests unitaires et d'intégration ne nécessitent pas de build sur des technologies comme React Native et Flutter. Ils devraient normalement pouvoir être exécutés dans cet ordre par des outils de CI/CD communs, tels que les Github Actions ou les Pipelines d'Azure Devops ou de Gitlab.
Les tests statiques peuvent être exécutés par les plateformes mentionnées précédemment en affichant le retour d'un linter par exemple. Nous conseillons néanmoins d'utiliser des plateformes spécialisées, telles que SonarCloud, qui remontent des indicateurs bien plus intéressants.
Les tests end-to-end quant à eux nécessitent des plateformes d'exécution spécifiques telles que Bitrise ou Azure AppCenter.
Les applications mobiles sont faites pour interagir des systèmes externes. Avec le monde réel d'abord au travers de capteurs : géolocalisation, connectivité (wifi, cellulaire, bluetooth), appareil photo, accéléromètre… Il existe d’autres systèmes qui vont communiquer avec votre application : les moyens de paiement intégrés, les stores et plus globalement le système d’exploitation et ses demandes de permissions... Il y aussi le navigateur et les autres applications du mobile.
Dans le cas où nous souhaitons automatiser les tests end-to-end, on va chercher à contrôler ces externalités de sorte à pouvoir s'assurer de leur reproductibilité de nos tests. Il ne pourra y avoir d'intervention humaine par définition donc on ne peut dépendre de facteurs externes sur lesquels nous n'aurons pas la main. Par exemple : comment automatiser le fait que l'utilisateur doive secouer le téléphone pour déclencher une fonctionnalité ? C'est impossible à priori.
L'automatisation des tests va donc nécessiter un environnement totalement maîtrisé et pour cela il va falloir s'abstraire des externalités.
La solution dans ce cas-là passe par le fait d'avoir la bonne approche en termes de conception logicielle :
Reste à permettre l'utilisation d'implémentations mockées. Concernant les tests unitaires et d'intégrations, les librairies de test classiques gèrent ça très bien. Par contre, dans le cas des tests end-to-end, les ressources sont moins nombreuses et il nous a fallu un certain temps pour bien comprendre quelle était la bonne approche. Il en résulte que pour les apps créées avec Expo (et donc par extension pour les applications React Native), il est possible de surcharger la configuration de Metro et d'ajouter la possibilité de builder une version mockée de l'application :
L'idée derrière est de ne jamais utiliser les modules à mocker directement dans votre application mais de passer par des implémentations Proxy. Et grâce à la modification de Metro précédente, vous pouvez choisir de charger en priorité des versions .mock.js au lieu des .js en exécutant la commande :
Ainsi, grâce un flow de CI/CD astucieux, vous serez en mesure de produire des builds spécifiques pour les tests automatisés. Il restera une charge de tests manuels à faire correspondant aux fonctions qui auront été mockées. Mais au final la quantité de tests end-to-end manuels restante sera grandement limitée et le gain en termes de temps à passer est tout à fait intéressant.
La mise en place de tests end-to-end est sans aucun doute le moyen le plus robuste pour fiabiliser votre application mobile sur le long terme. Nous l'avons dit plus tôt : ces tests sont longs à mettre en place et peuvent également être assez longs à exécuter.
Pour maximiser le rapport effort/effet, nous préconisons d'automatiser en premier lieu votre sanity check, car comme nous l'avons déjà dit c'est le scénario de test qui couvrira l'essentiel de vos régressions.
Techniquement, l'implémentation de tests end-to-end se fait communément avec Appium. La mise en place de la technologie demande un peu d'effort. Si vous êtes sur Azure, il vous faudra obligatoirement utiliser l'implémentation Java si vous souhaitez utiliser les devices farms (et vous devriez, voir plus bas).
Une approche plus simple mais plus coûteuse est d'utiliser des suites logicielles comme Katalon qui permettent d'exporter les tests générés en "no code", en Java notamment.
Il existe aussi des solutions extrêmement prometteuses : Maestro qui permet de déployer des tests automatiques excessivement simplement. Contrairement à Appium, la technologie cherche à gommer toute la pénibilité propre à l'implémentation de tests end-to-end, par exemple les fameux waitForElement(xxx) . Malheureusement la solution ne fonctionne que sur simulateurs à date. Elle n'est donc pas compatible avec les Device Farms que nous recommandons pourtant.
Si les tests automatiques doivent être implémentés par l'équipe QA (via Katalon par exemple), pour les cas simples, il n'y aura pas de difficultés particulières d'implémentation.
Enfin, pour que l'implémentation soit fluide, le seul pré-requis est que l'équipe de développement ai pris soin de positionner des "accessibility id" sur chaque élément qui sera utilisé par l'automatisation : aussi bien en lecture (ex: zone de texte à vérifier) que les éléments utilisés pour des interactions (ex: les boutons).
Les device farms sont des services qui permettent d'accéder à un catalogue de périphériques mobiles physiques (donc pas des simulateurs) et d'y exécuter des tests automatisés (et pas que). Nous en utilisons deux chez Dernier Cri : Amazon Device Farm de préférence, sinon celle d'Azure App Center. L'intérêt est d'une part leur coût d'accès modeste mais surtout d'avoir accès à un catalogue très vaste : on a globalement accès à des dizaines et des dizaines de périphériques différents avec en plus la possibilité d'y faire démarrer souvent la version de l'OS de son choix. Par exemple vous pouvez tout à fait démarrer un iPhone 8 sous iOS 11.2 pour tester un cas bien particulier. Mettre en oeuvre les devices farm demande une certaine expertise mais le jeu en vaut clairement la chandelle surtout si l'on arrive à les inclure dans un process d'automatisation.
Comme dit plus tôt, nous avons eu l'occasion d'expérimenter les device farms d'Amazon et Microsoft. Celle d'Amazon nous paraît plus simple à mettre en place. Toutes deux permettent une approche via des tests basés Appium. Néanmoins celle d'Azure ne fonctionne globalement bien qu'avec Appium pour Java, non sans mal d'ailleurs car la documentation n'est pas toujours très claire sur les pré-requis en termes de version de dépendances qui fonctionneront.
La device farm d'Amazon quant à elle accepte Appium pour Node, Ruby, Python et Java. Elle permet également une utilisation manuelle du téléphone, avec certaines limitations mais cela reste un excellent moyen de permettre la reproduction d'une anomalie sur un périphérique particulier que vous n'auriez pas en stock.
Enfin, les rapports générés par ces outils sont particulièrement intéressants : outre le fait de connaître la bonne exécution (ou non) de vos parcours, vous aurez accès à des métriques sur la consommation mémoire de pointe (peak memory) : utile pour diagnostiquer des implémentations non optimisées.
.png)
Les devices farms sont en synthèse le moyen le plus évolué et le plus proche possible de le réalité pour automatiser vos tests end-to-end.
L'élément essentiel d'une plateforme de développement mobile qui fiabilise votre application est le flow CI/CD qui sera mis en place. S'il est mal conçu, il cassera souvent ou les builds seront mis à disposition trop lentement. Or ce que nous voulons c'est bien une CI/CD optimisée, qui laisse chacune des parties prenantes attendre le moins possible, qu'il s'agisse de vos développeurs ou vos reviewers.
Chez Dernier Cri, nous recommandons usuellement la mise en place de deux types pipelines CI/CD :
Le pipeline devra ici, si l'on respecte le principe de la pyramide de tests, exécuter d'abord :
Dans un second temps, si votre CI le permet (ce qui est le cas avec Bitrise par exemple), nous conseillons d'exécuter en parallèle :
Le but étant de ne pas avoir à attendre la bonne exécution des tests end-to-end pour utiliser une application de recette dédiée à un usage interne. Les Pull-Requests pourront quant à elles être mergées si d'une part tous les voyants sont au vert en retour de la CI/CD suite à l'exécution des tests end-to-end et si d'autre part les équipes internes valident le contenu du build de recette.
Le deuxième pipeline est plus simple : il s'agit du pipeline qui permet la mise à disposition sur les stores d'un build de production. Ce pipeline doit normalement se baser uniquement sur du code issu d'une branche protégée (ex : master). Ainsi, l'un des préalables au code disponible sur cette branche est qu'il soit passé par le pipeline exécuté sur chaque Pull Request et qu'il soit tout garanti comme étant fiable à un certain nombre de niveaux (tests statiques, unitaires, intégration et end-to-end).
Nous aurions pu commencer l'article par ce point car c'est le plus essentiel mais il fera une très bonne conclusion : votre équipe technique doit se sentir concernée et être responsabilisé par rapport à la qualité de ce qu'elle produit. Tous les moyens techniques que vous pouvez mettre en place sont des garde-fous indéniables mais qui viendront uniquement en support de cet état-esprit. Si votre équipe ne se sent pas concernée, alors il est probable que ces moyens techniques ne soient jamais là d'une façon pérenne ou qui permettra d'en générer une forme de valeur.
Une fois publiée, la note de votre application doit vous préoccuper. Vous devez mettre en place des moyens de collecter de la donnée sur les usages défectueux (erreurs). Mais nous commençons ici à toucher du doigt un sujet tout aussi vaste : l'observabilité d'applications mobiles et qui aura son propre article dédié.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
