XP, rythme soutenable et commit

Parmi les pratiques d’ingénierie de développement logiciel qui sont mises en avant par XP, l’une des plus importantes me semble être l’intégration continue.

Le principe est simple :  vérifier à chaque modification de code source que celui-ci ne contient pas d’erreurs.

Comme souvent cette simplicité apparente cache une forme de complexité : d’abord il faut que l’intégration continue soit rapide. Au delà de 5 minutes pour que l’intégration continue soit terminée et le risque est (très) grand qu’un développeur ne fasse pas l’effort d’attendre de connaître le résultat de l’intégration pour commencer une nouvelle tâche.
Ensuite, cela nécessite que chacun dans l’équipe s’approprie un principe simple : « Le serveur d’intégration continu est représentatif de l’état du code ». Ce principe a un corollaire : « Si la dernière intégration et rouge, l’équipe doit porter son effort sur la réparation du build, quitte à mettre entre parenthèse les développements en cours ». Ce corollaire ne peut pas avoir dans mon esprit d’exception, que ce soit à cause d’un serveur svn inaccessible, d’une base de données qui a été arrêtée ou d’une tâche de l’intégration continue qui ne rend pas la main comme elle le devrait ; un build rouge empêche toute l’équipe de continuer à travailler, puisque plus personne ne peut commiter ou updater un projet correct.

Enfin, cela nécessite que chaque membre de l’équipe se sente impliqué dans le processus et éventuellement dans la réparation d’un build rouge. Ceci signifie par exemple qu’il me semble inconcevable de commencer à commiter à la fin d’une -dure- journée de travail. Illustrons cela par un exemple :
– 18h30 : les tests passent enfin au vert sur mon poste. Génial, je vais pouvoir commiter ce soir !
– 18h35 : j’update mes sources et relance les tests
– 18h45 : les tests passent au vert sur mon poste. J’update, pas de nouvelles modifications. Ouff, j’aurais pu y passer la nuit. Je commit.
– 19h : le serveur d’intégration continue compile l’application et passe les tests. Pas de chance le build est rouge
– Je commence donc à chercher l’origine du problème. Il est tard, j’ai envie de rentrer chez moi.
-19h15 : J’ai de la chance, ce n’est pas grand chose. J’ai rapidement corrigé. Je re-commit.
– 19h30 : le build est réparé ! Ca y est, j’ai bien mérité le droit de rentrer chez moi

L’exemple ci-dessus, dans lequel le problème a été résolu très rapidement m’inspire une règle générale : « ne pas commiter après 18h, à moins d’être prêt à ne pas sortir du travail avant 19h30 ». Et comme cela ne me semble pas être un rythme soutenable, j’en resterais personnellement à « ne pas commiter après 18h« . Je préfère préparer le commit, arriver tôt le lendemain, pour que le build ait lieu pendant la mêlée.

Publicités

2 Responses to “XP, rythme soutenable et commit”


  1. 1 Guillaume 1 août 2011 à 21:05

    Ca me parait un bon principe en effet.

    Dans notre équipe ce genre de build rouge vespéral se solde obligatoirement par une tournée générale de viennoiseries par le « fautif » 🙂

  2. 2 Benoît 1 août 2011 à 21:59

    Ça fait longtemps que je le propose aussi 😉


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s





%d blogueurs aiment cette page :