• Ce blog — désormais archivé — est en lecture seule.

symfony rencontre Hudson, Mantis et les autres

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, PhingCheckstyle, 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 :

fix issue 0000007

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) :

<!-- PHP CodeSniffer -->
<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 :

<!-- PHP dependency checker -->
  <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 :

<!-- PHP copy/paste analysis -->
  <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 :

<!-- PHP API Documentation -->
<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.

cd $WORKSPACE && phing main -Dworkspace=$WORKSPACE

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.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • FriendFeed
  • LinkedIn
  • MySpace
  • Netvibes
  • PDF
  • Ping.fm
  • RSS
  • Technorati
  • viadeo FR
  • Wikio
  • Yahoo! Buzz

Related Posts

Cet article a été publié dans Boulot, symfony avec les mots-clefs : , , , , , , , , , , . Bookmarker le permalien. Les commentaires et les trackbacks sont fermés.

7 commentaires

  1. Amokrane
    Le 27 août 2010 à 13 h 36 min | Permalien

    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 :)

  2. Youbs
    Le 1 septembre 2010 à 17 h 51 min | Permalien

    me likey

  3. eljam
    Le 13 septembre 2010 à 20 h 48 min | Permalien

    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

    • Le 15 septembre 2010 à 20 h 50 min | Permalien

      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.

  4. eljam
    Le 15 septembre 2010 à 22 h 46 min | Permalien

    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.

  5. Le 16 septembre 2010 à 17 h 36 min | Permalien

    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. :D
    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. :-°

  6. Le 10 novembre 2010 à 12 h 22 min | Permalien

    un bon article à partir de laquelle nous avons tous étudié

3 trackbacks

  1. [...] post: symfony rencontre Hudson, Mantis et les autres | William DURAND … No [...]

  2. Par | William DURAND - Développeur web indépendant le 22 mars 2011 à 2 h 34 min

    [...] 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 [...]

  3. [...] 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 [...]