Posts Tagged 'commit'

L’important c’est d’être régulier

Ce soir, je vais enfoncer une porte ouverte avec ce billet, mais parfois ça fait du bien !

Il y a des jours ou l’on se rend compte que des années d’expérience ne nous mettent pas forcément à l’abris des erreurs les plus basiques.
Explications : lundi nous avons fait une grosse séance de refactoring avec ma paire : renommage de toutes les méthodes d’une classe, extraction de comportement commun dans une classe mère …

Nous étions un peu grisés et franchement contents du rythme auquel nous avancions. A tel point que nous n’avons pas pu commité lundi soir car nous fumes victimes de demandes de support arrivées lundi soir.
Résultat ce matin, après un jour férié, nous pensions qu’il nous suffirait de tester rapidement nos modifications puis de les commiter. Las, nous avons découvert quelques bugs et avons passé plus d’une demi-journée pour rechercher où étaient les erreurs parmi nos nombreuses modifications.

Finalement, nous avons fait un revert sur la majeure partie de notre travail de refactoring. Grosse frustration …
J’en tire une conclusion qui sonne comme un rappel : commiter régulièrement nous aurait éviter ce genre de mésaventures !

Publicités

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.


Mises à jour Twitter