Chez Playmoweb, nous avons pour coutume de passer par un pair qui va relire le code avant qu’il soit définitivement intégré. Rien de nouveau dans cette pratique, nous utilisons GIT, ses branches et nous passons par des Pull Request (ou Merge Request en fonction de l’outil utilisé).

Dans le monde des applications web ou serveur, en plus de relire le code, il arrive que des Review App soient créées pour chaque nouvelle branche afin de pouvoir tester la nouvelle fonctionnalité.

Dans ce processus, un déploiement est fait sur un serveur et vous pouvez lancer le site web ou tester la nouvelle route de l’API. Très souvent, ces déploiements sont reliés à la Merge Request et sont très facilement accessibles.

Pour les applications mobiles, le processus peut paraître un peu plus complexe. Ce type de déploiement n’est pas pris en compte par les outils type GitHub ou GitLab qui ne proposent donc pas d’ouvrir l’environnement déployé depuis un simple lien.

L’ancienne méthode

Afin de mettre un peu de contexte, voici grossièrement ce que nous faisions avant :

• Une Merge Request est ouverte et assignée à un pair
• Le pair fait une revue du code
• Dans le doute il récupère la branche sur son poste
• Il ouvre le projet
• Récupère les dépendances
• Compile l’application puis la lance enfin sur son téléphone pour tester

Il faut avouer que ce processus n’est pas du tout propice aux tests manuels et laisse donc parfois passer des problèmes pas forcément visibles quand on se limite à une revue de code. Les revues de code ne permettent pas, par exemple, de détecter des soucis visuels sur une interface.

La nouvelle méthode

Pour simplifier cette revue, nous avons décidé de mettre en place une procédure afin de pouvoir tester l’application directement sur son téléphone.

Plusieurs points ont donc dû être traités :

• Build de l’application sur une Merge Request
• Déploiement de l’application pour la rendre facilement accessible.

Le deuxième point est assez critique, notamment pour iOS où nous devons signer l’application avec l’identifiant de l’iPhone. Ce processus d’enregistrement continuera d’être fait à la main, il doit cependant être simplifié. Sur Android l’installation est elle beaucoup plus simple et ne nécessite pas de processus spécial.

Pour cette partie nous avons donc décidé d’utiliser un service de Firebase : App Distribution. Ce service nous permet d’envoyer des applications pour être déployées et prêtes à être installées. Il nous permet aussi de gérer des listes de testeurs afin de choisir à qui on envoie les builds.

Il nous permet aussi, pour iOS, de faire enregistrer l’iPhone et de récupérer simplement les identifiants pour les ajouter à la signature.

Pour la partie build de l’application, c’était relativement plus simple. Chez Playmoweb nous utilisions déjà un outil qui nous permettait de les compiler et de les déployer vers les stores dès qu’un tag est fait sur le repository git. Il nous a donc suffi d’ajouter un déclenchement des compilations sur les Merge Request et d’associer à ce déclenchement un workflow précis :

1. Build de l’application
2. Déploiement sur Firebase App Distribution
3. Commenter la Merge Request avec le numéro de build

Ce workflow est efficace et le point 3 est la petite cerise sur le gâteau : nous n’avons pas à chercher le build correspondant à la merge request.

Bonus

Le petit plus de cette nouvelle manière de faire nos revues de merge request, c’est que nous pouvons aussi partager les builds à l’équipe qualité afin qu’elle teste avant de merger. Les retours seront donc intégrés directement sur cette même merge request plutôt que dans les suivantes.