Je viens de lire comme du petit lait le dernier livre blanc de Xebia sur la qualité logicielle. On apprécie toujours énormément lorsque d’autres expriment mieux qu’on ne saurait le faire ce que l’on pense déjà. Si vous êtes un “artisan du logiciel”, nul doute que vous vous y retrouviez aussi.

Les principes énoncés sont ceux que je m’efforce de mettre en oeuvre au quotidien, voici donc petit tour d’horizon des outils utilisés.

Le chapitre 6 du livre blanc propose 8 étapes de mises en oeuvre:

0 Gérer le projet

Il fait peu de chose mais c’est quand même un 3 en 1:

• gestion de ticket
• gestion de documentation (wiki)
• visualisation de code source

Un défaut: trac ne sait pas gérer le multi projet (il existe des solutions de contournement, par exemple déployer plusieurs instances de trac)

Trac sortit de la boite c’est bien, mais avec un peu de configuration et quelques plugins c’est Trac².

Plugins:

* TicketChangeset: permet de relier les tickets trac avec le code. Un haut niveau de qualité ne s’obtient pas du jour au lendemain. Relier le code aux tickets est salvateur lorsqu’un ticket est réouvert ou que la personne qui travaille sur un ticket n’est pas disponible.

* Ticket template: La qualité se travaille à tous les niveaux, vous connaissez le proverbe “crap in, crap out”, ticket template permet de fournir un modèle de rédaction des tickets que soit les bugs ou les demandes d’évolutions. Des tickets homogènes, exhaustifs sont un premier pas vers une meilleure qualité.

* Subticket: Dans l’idéal tous les tickets devraient représenter une quantité de travail plus ou moins équivalente afin de faciliter leur planification. Dans la réalité certaine tâches doivent être découpée, subticket permet de les relier.

Configuration:

Le workflow de Trac est facilement personnalisable, l’équipe doit se l’approprier en utilisant ses mots et ses propres étapes. Trac permet aussi de construire des rapports personnalisés, il ne faut pas hésiter à abuser de cette fonctionnalité.

Des alternatives à Trac:

Il en existe pléthore, par exemple Redmine, un clone de Trac qui monte, avec une équipe de développement très dynamique mais une communauté d’utilisateur pour l’instant plus restreinte.

Jira + Confluence: payant mais la suite logicielle d’Altasian est très aboutie. A noter qu’elle est aussi disponible en mode SaaS: jira studio

1 Gérer les sources

J’utilise Subversion, j’entends déjà hurler bouh, pourquoi ne pas utiliser un DVCS ?

• If it works don’t fix it ! (si vous avez des problèmes de merge se n’est pas la faute de SVN mais la votre)
• L’effort de formation pour exploiter réellement les possibilités des DVCS n’est pas négligeable
• A ce jour git ou mercurial ne fonctionne pas avec ticket change set plugin. Pour moi c’est un problème bloquant.

Mais bon je commence à utiliser git-svn…

Petit conseil qui ne mange pas pain, un post-commit-hook qui impose de mettre un commentaire avec un numéro de ticket trac est un moyen d’augmenter la qualité. Un autre qui vérifie l’encoding des fichiers sources commités peut eviter bien des surprises, sans oublier celui qui déclenche le build d’intégration continue.

Si vous n’utilisez pas svn, git ou mercurial vous avez probablement une mauvaise solution.

2 Automatiser la compilation et maintenir des versions stables

Maven 2 bien sûr, en attendant que maven 3 soit correctement intégré avec tous les outils que j’utilise. Le point critique avec maven est de savoir écrire des pom propres qui ramènent uniquement les dépendances réellement utilisée. Là aussi il existe des solutions supérieures sur le papier, je pense à gradle, mais maven est devenu un standard de fait intégré de facto avec tous les autres outils.

Une utilisation sérieuse de maven se fait de pair avec un repository d’archive locale (rien que gérer les dépendances non disponible sur un repo maven existant), nous utilisons archiva (le plus léger et le plus simple pour moi). Nexus est réputé mais je n’ai pas réussi à le faire fonctionner! Une autre option à surveiller est Artifactory.

3 Intégration continue

Hudson bien sûr. Oracle doit se mordre les doigts d’avoir perdu la main sur un tel projet. Il est intéressant de noter que cloudbees attaque le marché du Paas en partant de ce composant plutôt que la gestion de ticket ou de source (le marché est déjà encombré à ce niveau)

4 Déployer l’application

Après la lecture de Continuous Delivery on est forcément convaincu que tout doit être automatisé.

L’idéal est de contrôler les environnements d’éxécution à l’aide d’un Puppet ou Chef ensuite l’application que je gère est une simple webapp dans un tomcat. Le déploiement est fait à partir de Hudson et du plugin Promoted build qui permet de déclencher des tâches supplémentaires automatiquement ou manuellement.

Dans mon cas des étapes dev/recette/preprod/prod déclenchent des scripts shell qui:

• copie le war vers les environnements
• arrête tomcat
• archive les versions en cours
• nettoie les logs
• déploie la nouvelle appli
• redémarre tomcat

Je préfére cette solution à la fonction de déploiement par http de tomcat qui n’est pas toujours fiable (tomcat 5.5)

Il me reste encore à gérer automatiquement la base de donnée: vérification de la concordance du code et du schéma de base et mise à jour auto, déploiement des procédures stockées…

5 Faire connaitre l’état.

J’utilise simplement des alertes mails lorsque quelqu’un casse le build. Un buildwall ou autre nabaztag serait un ajout sympathique. J’ai aussi déployé sonar pour disposer d’un tableau bord de la qualité logicielle, l’intégration avec maven et hudson est enfantine et très efficace.

Mais le gros du travail reste à faire: personnaliser les règles qui seront suivis par sonar et décider des indicateurs que l’on va suivre et chercher à améliorer.

6 Intégrer les tests

Les étapes décrites jusque là demande peu d’efforts de la part de l’équipe de développement. C’est avec les tests que les choses sérieuses commencent…

J’utilise l’indétrônable papy des tests unitaires Junit et le non moins indispensable easymock pour rendre testable un code qui ne l’est pas à l’origine.

Bien sûr il n’y a pas de limite dans ce que l’on peut tester, fitnesse est à suivre pour mettre en place des tests d’intégration et selenium pour les tests UI.

Conclusion

Il n’y a pas de qualité logicielle sans développeurs qui soient convaincus de son importance mais le bon artisan se reconnait à ses outils et à la maîtrise qu’il en a.  Une bonne intégration des outils utilisés est essentielle (c’est une des forces des solutions microsoft).

Trac+Subversion+Hudson+Maven+Sonar+Archiva = une usine logicielle très performante pour un coût de licence de 0 ! Merci l’open source.

Et vous quels sont vos outils favoris ? (ou détestés!)