Bonjour, depuis un certain temps déjà, je me pose deux questions : « comment améliorer mon travail ? » et… « Comment améliorer mon travail ? ». La première question traite essentiellement de ce que je produis, du code écrit, des fonctionnalités que je mets en place, … tandis que la deuxième question définit mes conditions de travail. Autrement dit, qu’est-ce qui va faire la différence entre tout le monde et moi (jeune entrepreneur) ? Et qu’est-ce qui va me faciliter la vie et ainsi impacter la première question ?
C’est là que les outils que je vais présenter dans cet article interviennent. Aujourd’hui je parlerai de Hudson, Mantis, Phing, Checkstyle, PhpDocumentor, Pdepend et je montrerai l’interconnexion de tout ça sur un projet symfony.
Mantis
Mantis est un bug tracker, c’est-à-dire un rapporteur de défaillances. Il permet de consigner tous les problèmes survenus sur une application, de déclarer des priorités plus ou moins importantes mais surtout d’avoir un réel échange entre le rapporteur (le client) et l’équipe technique (composée de… moi). L’avantage d’avoir ce type d’outil dépasse ce que je viens de dire mais je m’en sers essentiellement pour avoir un endroit adapté où récolter les défaillances de mes applications. Mantis s’occupe d’avertir tous les gens concernés par mail, lorsqu’un bug est ajouté ou résolu par exemple. Ainsi, je ne perds aucun retour client auparavant stocké dans ma boîte mail sous forme de dizaines de mails et lorsque je résous un bug, le rapporteur concerné est prévenu automatiquement.
Nous allons voir pourquoi c’est si intéressant.
Hudson
J’ai déjà parlé d’Hudson, sans vraiment rentrer dans les détails parce que je ne vais pas réécrire ce qui a déjà été publié x fois, mais cette fois-ci je vais rentrer plus dans les détails. Au passage, Hudson est un serveur d’intégration continue.
Pour un projet symfony, je crée un projet freestyle, connecté à Git avec un déclencheur sur tout changement dans le repository distant. J’ajoute ensuite une succession de tâches symfony :
- création du répertoire log/
- suppression de la base de tests SQLite
- création de la base de tests
- tests
Ceci est un projet basique qui me permet d’avoir une intégration continue et une alerte rapide par mail si un problème survient.
Oui mais voilà, ce n’est pas suffisant, on peut mieux faire. J’ai parlé de Mantis juste avant, il serait bien de pouvoir connecter Hudson avec Mantis. C’est justement ce que fait le Mantis Plugin pour Hudson. Ainsi, si je « commit » une modification qui a résolue un bug, exemple :
Le plugin va pouvoir lier ce changement avec la page Mantis du bug et ajouter les informations liées au commit. Dorénavant, lorsque je « commiterai » un fix, le rapporteur sera prévenu de la résolution du bug qu’il aura soumis. Le gain de temps est indéniable.
Configuration Hudson :
Mais on peut (encore) faire mieux d’une autre manière, c’est-à-dire que si la build est un succès, pourquoi ne pas la déployer. Pour avoir un changement, je dois faire un « push » vers le repository distant. Or, on ne « push » pas tous les jours ou du moins, pas derrière chaque commit. Ce serait un peu perdre l’avantage du mode décentralisé de Git. Ainsi, quand je choisis de faire un « push » c’est que j’estime avoir suffisamment modifié mon projet. Ceci m’amène à penser qu’il devient intéressant de le déployer.
Merci à Capistrano (lire ici mon article sur le déploiement d’applis symfony et diem avec Capistrano) et au SSH Plugin d’Hudson. Ce plugin n’est pas des plus parfaits mais il fonctionne. Si la build passe, je lance mon déploiement. Normalement, le déploiement n’échoue pas, si c’était le cas alors : capistrano ferait un rollback sur la dernière version fonctionnelle et les logs Hudson m’indiqueraient le problème. Je peux donc être rassuré de ce côté-là.
Jusqu’à présent, je n’ai parlé que d’automatisation des aspects « après développement » à savoir les feedbacks client et le déploiement. Ce sont les deux points essentiels après réussite des tests. Pour autant, Hudson peut aider l’équipe de développeurs en effectuant une série d’analyses.
Phing : l’Ant des temps modernes (ou pas)
Phing, c’est Ant (utilisé dans le monde Java) version PHP, en quelques mots, un outil d’automatisation de tâches répétitives. Il faut connaître Ant pour comprendre qu’il est génial de disposer d’un outil semblable pour PHP. C’est grâce à cet outil que je génère des rapports d’analyse.
Phing s’installe via PEAR.
Checkstyle : mon code a du style !
Checkstyle est un outil de contrôle de code. Il vérifie le style du code écrit (indentation, commentaires, …). Pour l’utiliser avec PHP, il faut PHP_CodeSniffer (on abrège en phpcs) et le Checkstyle Plugin d’Hudson. Pour l’utiliser avec symfony, on ajoutera le standard symfony : http://github.com/denderello/phpcs-symfony ou si vous utilisez la toute dernière version : http://github.com/willdurand/phpcs-symfony.
Configuration Hudson :
Configuration du build.xml (Phing) :
<target name="phpcs">
<echo msg="PHP CodeSniffer..." />
<exec command="phpcs --standard=Symfony --report=checkstyle ${workspace}/apps ${workspace}/lib/filter ${workspace}/lib/form ${workspace}/lib/model ${workspace}/lib/validator ${workspace}/test" > ${workspace}/log/checkstyle.xml" escape="false"></exec>
</target>
Et aperçu du résultat :
Pdepend : analyse de code statique
Pdepend, analyseur de code statique, permet de calculer des indices (couplage, instabilité, …) afin de déterminer la qualité du code de la build. Pour cela, il nous faut le Jdepend Plugin d’Hudson et avoir installé pdepend.
Configuration Hudson :
Configuration du build.xml :
<target name="pdepend">
<echo msg="PHP Depend..." />
<exec command="pdepend --jdepend-xml=${workspace}/log/jdepend.xml ${workspace}/apps,${workspace}/lib/filter,${workspace}/lib/form,${workspace}/lib/model,${workspace}/lib/validator,${workspace}/test" escape="false" />
</target>
DRY ! Analyser les répétitions de code
Don’t Repeat Yourself, adage symfony, on souhaite ici analyser le code dupliqué. Pour cela, on utilise phpcpd (toujours via PEAR) ainsi que le DRY Plugin d’Hudson.
Configuration Hudson :
Configuration du build.xml :
<target name="phpcpd">
<echo msg="PHP Copy/Paste..." />
<exec command="phpcpd --log-pmd ${workspace}/log/pmd.xml ${workspace}/apps ${workspace}/lib/filter ${workspace}/lib/form ${workspace}/lib/model ${workspace}/lib/validator ${workspace}/test" escape="false" />
</target>
Et aperçu du résultat :
PhpDocumentor : génération de la documentation du projet
PhpDocumentor permet de générer la documentation d’un projet, tout comme Javadoc le ferait. Voici la configuration du build.xml :
<target name="phpdoc">
<echo msg="PHP Documentor..." />
<phpdoc title="API Documentation"
destdir="${workspace}/doc"
sourcecode="yes"
defaultpackagename="sfProjetsGagnants"
output="HTML:Smarty:PHP">
<fileset dir="./apps">
<include name="**/*.class.php" />
</fileset>
<fileset dir="./lib/model">
<include name="**/*.class.php" />
<exclude name="**/Base*" />
</fileset>
</phpdoc>
</target>
On pourrait ajouter le DocLinks Plugin pour Hudson afin de lier la documentation générée à chaque build.
Invoquer Phing
Pour invoquer Phing dans Hudson, on peut soit utiliser le plugin qui gère Phing soit utiliser une commande shell. Je préfère la commande shell pour pouvoir passer des paramètres à mon script.
Couverture de code
Là je vous laisse lire cet article qui explique comment obtenir des rapports de couverture de code symfony dans Hudson.
Conclusion
En plus d’automatiser un certain nombre de tâches, j’obtiens des retours sur mon projet : des retours client grâce à Mantis et des retours sur la qualité de mon travail. Aujourd’hui, des outils pour PHP sont là, il est clair que PHP s’industrialise et grâce à la qualité du framework symfony, il devient intéressant d’adopter les bonnes méthodes et d’utiliser ces outils. PHP, ce n’est plus « Un mini-chat en PHP » par le Site du Zéro.
Il n’est jamais trop tard pour commencer à bien travailler.
7 commentaires
Pas mal la présentation que t’as mis en fin d’article, j’aime bien le côté itératif qui en ressort! On démarre simple et on fait évoluer progressivement!
Dans la boite où je fais mon stage (un éditeur de logiciels) ils utilisent Rally (équivalent de Mantis) et Cruise Control (pour le serveur CI).
Par contre c’est sympa ton truc, je vais m’en inspirer et piquer les trucs dont j’ai besoin au fur et à mesure pour mon projet actuel
me likey
Bonjour je suis un peu un novice sur hudson, on le trouve où le build.xml que l’on doit changer pour chaque plugin ?
Merci
Bonjour,
Le build.xml dépend de Phing (automatiseur de tâches style Ant) et non de Hudson. Pour ma part, j’attache un build.xml à la racine de mon projet Symfony.
Cordialement.
D’accord effectivement ça me faisait plus penser au build.xml lors de la création de serveletJava, je comprends mieux maintenant.
Merci beaucoup pour l’information.
Merci pour cet article qui fait un bon tour d’horizon des technologies que l’on peut aujourd’hui utiliser sur des projets PHP.
De notre côté, pour le Site du Zéro, on utilise déjà Capistrano / Webistrano, on met en place Hudson et pas mal de plugins.
La petite remarque à laquelle je ne m’attendais pas à la fin, sur le TP mini-chat du Site du Zéro dont je suis l’auteur, m’a bien fait sourire.
Heureusement qu’il ne s’agit que d’un tout premier TP d’introduction pour débutants, et non pas d’une méthode sur la gestion de projets. :-°
un bon article à partir de laquelle nous avons tous étudié
3 trackbacks
[...] post: symfony rencontre Hudson, Mantis et les autres | William DURAND … No [...]
[...] 22 mars 2011Bonjour,Depuis quelques temps j’ai repris mes travaux déjà énoncés symfony rencontre Hudson, Mantis et les autres. J’ai mis à disposition un template générique d’un build.xml pour Phing [...]
[...] 22 mars 2011Bonjour,Depuis quelques temps j’ai repris mes travaux déjà énoncés symfony rencontre Hudson, Mantis et les autres. J’ai mis à disposition un template générique d’un build.xml pour Phing [...]