Souvenir d’eXtreme programming #12 : L’intégration continue
Continuons notre série en parlant un peu d’une pratique qui n’est pas propre à XP, mais tout processus de développement discipliné : l’intégration continue.
Le but est d’éviter un phénomène classique de rétention de source : Un développeur garde du code sur son poste plusieurs jours (semaines/mois ?) sans le réintégrer dans le système de gestion de source. Lorsqu’il effectue la réintégration, il peut passer un long moment à régler les conflits avec d’autres modifications effectué. Et dans certains cas, une réintégration un peu brutale peut provoquer d’autre problèmes (le fameux effet papillon).
Pour éviter cela, l’intégration continue consiste à réintégrer très régulièrement les sources dès que le développeur a atteint un état stable de l’application (c’est à dire dès que ses tests passent).
Un élément nécessaire pour l’intégration continue est l’utilisation d’un outil de gestion de version comme CVS ou Subversion. Dans notre cas, vu l’utilisation de Visual Studio, nous avons naturellement utilisé Visual Source Safe (VSS). VSS était configuré en mode verrou partagé. Cela signifie que plusieurs développeurs peuvent travailler sur le même fichier (C’est un peu comparable au mode de fonctionnement de CVS). C’est lors de la réintégration que l’on gère les conflits éventuels.
Lors de la présentation de l’organisation spatiale, j’avais parlé de la machine de build. Lorsqu’un binôme a terminé une tâche élémentaire, et que tous les tests passent sur sa machine, les sources sont réintégrés dans VSS, puis le binôme se rends devant sur la machine de build, récupère tous les sources de VSS (et pas seulement ceux qu’ils ont modifiés), recompile l’application et lance les tests. Si un problème se produit, ils doivent le corriger avant de retourner à leurs poste (ou de rentrer chez eux).
Lorsque les tests se passent bien sur la machine de build, les binaires sont copié dans un répertoire de livraison et installé sur le serveur de pré-production, avant d’éventuellement mis en production si l’équipe marketing valide cette version. Au départ afin de signaler qu’une livraison a été faite, on utilisait une crécelle, mais le bruit était un peu trop fort et son utilisation n’a pas duré.
Après une réintégration réussie, le binôme peut récupérer sur son poste de travail les dernières versions de code sur VSS, puis démarrer une nouvelle tâche. Et systématiquement avant de commencer à travailler le matin on récupère les dernières versions.
L’utilisation de la machine de build s’est vite généralisé, et finalement peu de problème de conflit ont eu lieu, ce qui fut un grand changement par rapport au passé (alors même qu’il y avait peu de code dont la responsabilité était partagée). Aujourd’hui la machine de build serait sans doute remplacé par un serveur de construction automatique comme CruiseControl.Net.
Malgré cela, l’intégration continue, couplée avec les tests unitaires, est la clé du succès de la responsabilité partagé du code. On en reparlera.
A suivre