Chez Affluences, nous utilisons pour la plupart de nos projets le workflow gitflow pour la gestion de nos répos. Avec l’arrivée de nouvelles personnes dans l’équipe, nous avons été confrontés à deux principaux problèmes qui ont impacté notre capacité à livrer des fonctionnalités toujours aussi rapidement.
Problèmes rencontrés par nos équipes
Lors du processus de développement de nos nouvelles fonctionnalités, nous nous sommes heurtés à la problématique de ne pas avoir tous nos développements sur nos environnements de tests et de production sans avoir à déployer une nouvelle version.
Exemple avec le scénario suivant :
- Nous compilons et déployons une nouvelle version embarquant une nouvelle fonctionnalité sur notre environnement de test
- Nous compilons et déployons une autre version embarquant elle aussi des nouveautés.
- La première version n’est par conséquent plus disponible.
Un jonglage entre différentes versions était donc nécessaire !
Autre problème rencontré : lorsque nous développons de nouvelles fonctionnalités en parallèle, il arrive que les différentes branches utilisées pour chacune de ces fonctionnalités se désynchronisent, notamment lors du développement de fonctionnalités importantes. Les merges de branche étaient devenues très compliquées avec une gestion des conflits quasi systématique.
Partant de ce constat, nous avons étudié les différentes options de gestion d’un répo et avons décidé d’implémenter celle qui permettrait de solutionner les problèmes décrits précédemment : le Trunk Based Development (TBD) associé à des Feature Flags (FF).
Trunk Based Development et Feature Flags
Il s’agit d’un workflow git qui se base sur une seule branche principale qui contiendra le code qui doit être prêt et livrable en prod à tout moment.
Tout nouveau développement doit partir de cette branche et les branches de développements ne doivent pas avoir une durée de vie de plus de 3 jours pour garder la synchronisation optimale des branches.
Ce paradigme est généralement associé à l’utilisation de Features Flags : il s’agit d’un processus de développement qui utilise des variables conservées dans un endroit externe à l’application. Elles sont récupérables de façon dynamique et servent à activer ou désactiver des fonctionnalités impactant directement les environnements sans avoir à compiler ou ni déployer du code.
Mise en place de ces concepts
Trunk Based Development
Le concept est simple : toutes les nouvelles fonctionnalités partent de la branche principale ! Celles-ci doivent être merge à nouveau sur la branche principale le plus vite possible pour éviter les conflits.
Cette nouvelle philosophie nous a demandé de revoir nos méthodes de travail au quotidien : Nous essayons désormais de découper nos tâches au maximum afin que chacune d’entre elles soient les plus atomiques possibles de sorte à ce qu’elles soient les plus indépendantes les unes des autres.
Nous avons également revu nos pratiques en matière de Merge request et de Code Review : pour qu’une branche soit active le moins de temps possible, il faut que les revues de code soient effectuées le plus rapidement possible. Cela n’est possible que lorsque les Merge Request sont suffisamment petites et que l’équipe partage les mêmes conventions de développement pour se concentrer sur le fond plutôt que sur la forme du code produit.
Enfin, nous avons renforcé notre stratégie de tests automatisés pour nous assurer que la branche principale ne contient pas de code défectueux. Etant donné que c’est la seule qui contient le code livrable en production, nous avons renforcé notre batterie de tests, notamment en ajoutant des tests sur les composants front Angular que nous développons.
Feature Flags
Dans la mesure où nous utilisons la suite Gitlab, nous avons décidé d’utiliser les fonctionnalités déjà disponibles dans cet outil. En effet, la plateforme met à disposition une interface graphique pour la gestion des Features Flags :
Une fois les variables configurées, il faut que notre application soit en mesure de les récupérer pour les exploiter. Pour cela, Gitlab propose d’utiliser Unleash qui agit en tant que proxy entre Gitlab et notre application. Celle-ci se connecte ainsi à ce composant pour récupérer les Feature Flags configurés et activer ou désactiver des fonctionnalités de manière dynamique.
Avantages et perspectives
En combinant les deux solutions, nous obtenons un système efficace et solide :
- Moins de stress sur la gestion du code
- Gestion des fonctionnalités disponibles sur l’application en temps réel avec la possibilité de filtrer par groupe d’utilisateurs ou par attributs
- Amélioration de notre processus de développement et de la qualité de nos productions.
Nous avons appliqué avec succès ce principe sur notre plus grosse application sur laquelle plusieurs développeurs travaillent régulièrement en même temps. Notre ambition est désormais de répliquer ce mode de fonctionnement sur d’autres applications et micro-services que nous produisons afin d’homogénéiser nos pratiques de développement au sein de l’équipe tech et de bénéficier des avantages que procurent ces procédés !