Planifier la publication de votre app avec le train de livraison mobile
Dans le monde du développement agile, peu de choses peuvent s'avérer plus frustrantes qu'un processus de livraison à l'arrêt. Une telle situation peut se produire lorsque les Product Managers sont dans l’incapacité de travailler sur la prochaine version d'une app car celle-ci est développée par différentes équipes, travaillant sur différents aspects de la storyline.
Lors de l'élaboration du planning de livraison, on réalise rapidement que les applications développées par plusieurs équipes en parallèle ont besoin de coordination pour être livrées dans les temps. C'est là que la notion de « train de livraison mobile » entre en jeu. En adoptant cette démarche, vos différentes équipes de développeurs pourront publier des apps dans les différents app stores de manière simultanée.
Le concept n'a rien de nouveau et rentre dans le cadre du Scaled Agile Framework (qui vise à appliquer les principes de l'agile à grande échelle). Le train de livraison mobile décrit une méthode spécifique pour livrer un logiciel, et peut être utilisé par tout type de service, petit ou grand, qui travaille sur une seule app avec différentes équipes.
Comment prendre le train de livraison mobile
Découvrons un train de livraison mobile. L’image ci-dessous représente un exemple simple, avec une phase de développement de 2 à 4 semaines (qui correspond à la plupart des cas).
À un jour et une heure définis (un lundi à 15h par exemple), le code est gelé. Jusqu'à cet instant précis, les équipes ont la possibilité de contrôler, tester et incorporer les nouvelles fonctionnalités à la branche principale qui doit faire partie du train. À 15h, une personne créera une branche de livraison à partir de la branche principale, de manière automatique ou manuelle.
Cette branche de livraison fera l'objet d'une phase finale de tests d'intégration. Lors de cette phase, tous les membres de l'équipe devront vérifier que les nouvelles fonctionnalités marchent bien comme prévu. Si un problème est détecté sur la branche de livraison, le bug sera corrigé sur celle-ci et incorporé par la suite à la branche principale.
Dès le moment où le code est gelé, un nouveau cycle de développement démarre, et toutes les équipes qui contribuent au projet peuvent démarrer un nouveau sprint de développement. Le principal avantage du train de livraison mobile est que chacun sait quand aura lieu la prochaine livraison et peut organiser son travail en conséquence.
Qui est aux commandes du train ?
Chaque livraison doit être pilotée par une équipe ou une personne. Il peut s'agit toujours de la même personne/équipe, ou bien l'effort peut être réparti entre tous les développeurs. Dans tous les cas, une personne doit avoir la fonction de RTE (Release Train Engineer). Cette personne est chargée d'obtenir toutes les informations nécessaires pour la livraison (par exemple les notes de version, les nouvelles images pour le store, etc.). Cette personne doit également organiser un point hebdomadaire pour informer le reste de l'équipe des versions en cours et des problèmes existants sur la version actuellement en production.
Intégrez toujours les tests à votre planning
Si une équipe opte pour des tests en interne avec des collègues, des tests en bêta avec de vrais clients et un déploiement par étapes, le train de livraison mobile peut ressembler à ça :
Cet exemple pourrait décrire un train de livraison Android. Les phases de développement et d'intégration sont les mêmes que dans la version simple du train. Une fois que l'application a été testée en interne ou en externe, le RTE importe l'application dans le canal bêta. Dans ce canal, de vrais clients reçoivent une notification de mise à jour sur leur appareil pour des tests.
Lors de la phase de bêta-test, les bêta-testeurs peuvent transmettre leurs retours directement sur l'app store. En parallèle de ces retours, les crashs peuvent être enregistrés dans des outils tels que TestFlight, HockeyApp or Crashlytics.
Après la phase de bêta-test de l’application, vient la phase de déploiement par étapes. À ce stade, le RTE peut définir le pourcentage des utilisateurs qui recevra la mise à jour. Dans ce cas précis, l'application sera d'abord déployée pour 10 % des utilisateurs, puis 20 %, puis 50 %. À chaque étape, les commentaires ainsi que les outils de suivi des crashs doivent être contrôlés pour identifier tout problème éventuel.
Apprenez-en plus sur les tests d'applications mobiles avec Applause
Si un bug apparaît lors de l'étape de déploiement à 20 %, l'équipe a la possibilité de réagir et d'utiliser la grille d'évaluation des bugs pour mobile afin de décider si le problème nécessite un correctif. Si tel est le cas, le train ne doit pas atteindre l'étape suivante de déploiement à 50 %. Le problème doit d'abord être résolu pour les 20 % d'utilisateurs concernés. Une fois le problème corrigé et vérifié, le train peut reprendre sa route et passer à l’étape suivante du déploiement.
Comme dans la version simple du train, seul le RTE (ou l'équipe désignée) gère le processus de livraison après le gel du code. Toutes les autres équipes poursuivent le développement « normal ».
Comment mettre en place un train de livraison mobile
Avant de lancer un train de livraison mobile dans votre entreprise, vous devez définir la durée de chaque étape. Dans la plupart des cas, la phase de développement dure de 2 à 4 semaines. Mais vous devez ensuite définir combien de temps vous voulez consacrer aux tests d'intégration, aux bêta-tests et aux phases de déploiement. Voici un exemple :
- 10 jours de développement
- 2 jours de tests d'intégration
- 3 jours de bêta-tests
- 2 jours de déploiement pour 10 % des utilisateurs
- 4 jours de déploiement pour 20 % des utilisateurs
- 2 jours de déploiement pour 50 % des utilisateurs
Au total, il faut 23 jours pour qu'une nouvelle version de l'app soit en ligne pour 100 % des clients. Pour certaines apps et certains clients cela peut être trop rapide, pour d'autres c'est bien trop long. Chaque équipe/entreprise doit définir la durée de ses phases.
Si vous voulez créer un train de livraison mobile plus avancé pour iOS, vous pouvez supprimer le déploiement par étapes au profit d'une phase de tests internes plus complète avec vos collègues. Vous pouvez distribuer l'app en interne en utilisant des outils tels que TestFlight ou HockeyApp. Une fois la phase de tests internes terminée, vous pouvez utiliser les mêmes outils pour envoyer l'application à vos clients bêta. Il ne restera plus ensuite qu’à importer l'application dans l'App Store et la proposer directement à 100 % de vos clients.
Aspects importants à considérer lors de la planification des livraisons
Créer et utiliser un train de livraison mobile est une excellente idée, mais suivre et maintenir le processus à chaque livraison peut s’avérer difficile. Voici quelques conseils pour mettre toutes les chances de votre côté :
- Une équipe/personne doit être en charge de la coordination et la livraison de la version.
- Organisez un point hebdomadaire/bi-hebdomadaire pour permettre aux équipes concernées d’échanger.
- Planifiez et annoncez les dates de départ du train plusieurs semaines/mois à l'avance.
- N'acceptez que le code qui a été vérifié et testé.
- N'acceptez que le code qui dispose de tests unitaires et (si besoin) de tests automatisés de bout en bout.
- Ne prenez pas de passagers en retard. N'incorporez pas à la branche principale de code encore en cours de développement le jour du gel. Ce code n'a pas été suffisamment contrôlé et testé.
- Optez si possible pour un déploiement par phases.
- N’oubliez pas de suivre les performances de la version après sa publication.
