Archives pour août, 2008

Identifier ses builds avec Hudson

L’une des fonctionnalités de l’outil d’Intégration Continue Hudson est de permettre un déploiement automatique de son application sur un serveur d’intégration.
On pourra ainsi déployer sa webapp sur son Tomcat, toutes les nuits, de façon à offrir chaque matin la dernière version de l’application.

Dans ce cas, il est très utile de connaître précisément les informations du build d’Hudson, comme par exemple le numéro du build, la date du build, etc.
Hudson, lorsqu’il démarre un nouveau build, va définir un certain nombre de variables d’environnement très utiles, qui pourront alors être utilisées dans le fichier pom.xml, ou dans n’importe quelle ressource de l’application (pour peu qu’elle soit filtrée par Maven).
Ces variables d’environnement sont les suivantes :

  • BUILD_NUMBER : Le numéro du build, « 42″ par exemple.
  • BUILD_ID : L’identifiant du build, tel que « 2008-08-08_08:08:08″ (format YYYY-MM-DD_hh-mm-ss).
  • JOB_NAME : Le nom du projet.
  • BUILD_TAG : Une chaine de caractères correspondant à « hudson-${JOBNAME}-${BUILD_NUMBER} ». Permet ainsi une identification précise du build.
  • EXECUTOR_NUMBER : Le numéro d’identification de l’exécuteur qui s’est chargé du build.
  • JAVA_HOME : Si le job Hudson est configuré pour utiliser un JDK spécifique, cette variable est définie par le JAVA_HOME de ce JDK.
  • WORKSPACE : Le chemin absolu vers l’espace de travail de ce job Hudson.
  • HUDSON_URL : L’URL complète d’Hudson, du type « http://server:port/hudson/ ».
  • SVN_REVISION : Pour les projets utilisant Subversion, cette variable conserve le numéro de révision du module.
  • CVS_BRANCH : Pour les projets utilisant CVS, cette variable conserve le nom de la branche du module, si celle-ci existe.

On utilisera alors dans le pom.xml, ou dans n’importe quelle ressource filtrée, le nom de la variable d’environnement souhaitée, encadrée par ${}. Pour obtenir le numéro du build, il suffira donc d’écrire ${BUILD_NUMBER}.

Start Slide Show with PicLens Lite PicLens

Sortie de Nexus 1.0

La société Sonatype vient de délivrer la version 1.0 de Nexus, leur gestionnaire de repositories Maven 2.

Quelques fonctionnalités intéressantes :

  • Pas d’installation nécessaire (il suffit juste de dézipper l’archive).
  • Aucune base de données n’est nécessaire !
  • Interface sobre et très agréable à utiliser (utilisation d’ExtJS).
  • Propose une API REST.
  • Offre différents flux RSS pour suivre l’ajout des nouveaux artifacts sur les repositories.
  • Intégration à Eclipse grâce au plugin m2eclipse.
  • Possibilité de déployer les artifacts directement via l’interface.
  • Beaucoup d’autres choses…

Bref, Nexus s’annonce comme l’une des meilleures solutions pour gérer ses repositories Maven 2.

Une page de démonstration est d’ailleurs disponible ici.

Fiddler

Récemment, dans la mission pour laquelle je travaille, nous avons eu besoin d’optimiser le trafic réseau, de façon à rendre l’application plus agréable sur des réseaux à fortes latences.

Nous avons trouvé un outil vraiment très agréable à utiliser, du nom de Fiddler. Comme le dit la description sur le site, Fiddler est un proxy HTTP destiné au débugguage, qui va tracer ainsi tout le trafic réseau entre la machine locale et le réseau (Internet ou Intranet).





Certes ce n’est pas le seul outil à proposer ce genre de fonctionnalités, mais Fiddler est particulièrement facile et agréable à utiliser.

A noter que la version 2 de Fiddler permet également de gérer le protocole HTTPS (nécessite l’installation de la version 2 du framework .NET).

Start Slide Show with PicLens Lite PicLens