Press "Enter" to skip to content

Désolé, je n’ai pas d’article de référence sur l’Isolation Continue mais je suis certain de ne pas l’avoir inventé ! Voici un exemple d’article qui utilise le terme : https://damianbrady.com.au/2017/07/12/continuous-integration-not-continuous-isolation/

Dans tous les cas, cette pratique de fusionner les branches au dernier moment n’est pas, en soi, novatrice. Par exemple un de nos collègues avait précédemment travaillé à Mozilla et il nous disait que c’est ainsi qu’ils fonctionnaient. Il y a également cette présentation de Les Furets qui décrit un fonctionnement similaire à ce que nous faisons :

Concernant les problématiques d’intégration et l’outillage, fondamentalement il s’agit des mêmes technos que pour l’intégration continue, en l’occurence un GitLab CI couplé à un Jenkins. La différence est qu’au lieu de valider que tout se passe bien sur la branche d’intégration, nous validons que tout se passe bien sur les feature branches.

Idéalement, on veut même vérifier que ces branches sont compatibles entre elles, qu’elles s’intègreraient bien les unes avec les autres. C’est en l’occurrence exactement ce que décrivent Les Furets dans leur présentation dont j’ai mis le lien plus haut : ils vérifient que toutes les branches fonctionneraient ensemble si on les fusionnaient.

Notre équipe n’en est pas encore à ce niveau de maturité, l’outillage se contente de valider que tout va bien sur les branches, à chaque push. Néanmoins ils se sont donné le process de systématiquement rebase les branches dès lors que master change. En d’autres termes, dès lors qu’une mise en production est effectuée, c’est à dire dès lors que le code de référence est modifié, alors ces modifications sont reportées sur toutes les branches en cours de développement. Tout problème d’intégration sera alors détecté à ce moment-là, puisque la récupération de ces changements déclenchera un nouvelle exécution des tests d’intégration sur cette branche.

Cette approche est sous-optimale, dans le sens où un mécanisme comme celui des Furets l’aurait détecté plus tôt. Néanmoins, elle nous satisfait pour le moment puisqu’elle permet de quand même détecter les problèmes avant le dernier moment. Il faut également voir que dans notre contexte de petit passage à l’échelle, les développeurs restent très proches et entrevoient/prévoient à l’avance les interactions entre les fonctionnalités/branches même lorsqu’ils ne sont pas dans la même équipe.

Enfin, point important, nous faisons tout pour réduire au maximum la durée de vie des branches. Tout le système tient debout parce que les branches sont rapidement fusionnées après leur création. Nous avons vécu quelques cas de branches qui ont vécu très longtemps et cela a été une source sans fin d’effort et de frustration. Maintenant que la machine tourne comme une horloge et que les fonctionnalités sont mises en production quasiment aussitôt la fin du développement, ce genre de problème devient rarissime.

Top