git bisect saved my day !

This morning one of the Jenkins job went red, 5 tests were failing, and it was very difficult to find out which commit caused the break (69 commits were concerned), I used git bisect to run maven tests to find the guilty one. Here is a quick howto:

  • find a stable commit (in my case it was 2ea34cf09cc83804cdcc445476bfb597c617a034)
  • write a short script (myScript.sh) allowing you to run the tests:
#!/bin/sh
 mvn -f path/to/my/pom.xml -Dtest=MyTestClass test
  • git bisect start HEAD 2ea34cf09cc83804cdcc445476bfb597c617a034
  • git bisect run ./myScript.sh

That’s all, in a few runs (6 in my cases), git found out the commit causing the test failure, a simple git revert and tests were back to green !

Livraison continue avec Maven / Shell

Livraison continue


Après l’intégration continue, c’est le mot à la mode sur le web ces derniers temps. Le concept est très simple, ceci consiste à réduire le nomrbe d’étapes nécessaires au déploiement d’une application. Pour le mettre en pratique il y a plusieurs solutions, utiliser un environnement PaaS similaire pour vos développements et la production (en utilisant la nouveauté Micro Cloud Foundry de VMWare, utiliser une instance EC2 spéciale). Et vous pouvez utiliser Chef pour gérer et automatiser votre configuration. Bien que ces solutions soient très interessantes, je trouve qu’elles sont finalement trop puissante et difficile à mettre en oeuvre dans des cas simples.
Je vais expliquer ici ma solution “simple” utilisant maven, des scripts shell et la détection du nom de la machine.

Exemple d’archive de livraison

Comme un exemple est mieux que des milliers de mots, vous trouverez un exemple de ma solution dans un dépot github Easy Release Archive. C’est un projet maven construisant un fichier zip contenant tout ce qui doit être déployé, et un script d’exemple pour configurer le serveur Glassfish.

Quel contenu ?

Pour comprendre comment il fonctionne, la meilleure chose à faire est de regarder son contenu

  • un fichier assembly.xml décrivant les fichiers à inclure, leurs noms finaux et leurs localisations.
  • quelques scripts dans /src/main/resources
    • sanityCheck.sh : un script permettant de charger les variables en fonction du nom d’hôte de la machine et de s’assurer que les variables nécessaires sont correctement configurées
    • setupGlassfish.sh : un script simple permettant de configurer un serveur Glassfish avec les datasources et d’autres paramètres
    • un dossier global contenant les ficheirs de configuration globaux
    • un dossier par nom d’hôte (dans mon cas samva-mbp) contenant un script shell shell/envSetup.sh permettant de configurer les variables nécessaires et un dossier config pour les fichiers de configuration propres à l’environnement.
  • un fichier pom.xml file décrivant les versions des artefacts à utiliser dans la construction du fichier zip et le cycle de vie maven à adopter.

Un simple mvn package permettra de construire l’archive zip contenant tout ce qui est décrit dans le fichier assembly.xml. Il suffira ensuite de décompresser le zip et d’exécuter le ou les scripts correspondant au déploiement pour que celui-ci se fasse simplement, on peut même demander à son serveur d’intégration continue de le faire pour avoir un système simple mais puissant de livraison continue.

ejb-client package + JRebel + Glassfish

JRebel ?

J’utilise JRebel pour accélerer mon cycle de développement. C’est un outil impressionnant qui permet de développer une application Java EE comme du PHP. Pas de redéploiement, tout ça au prix d’une petite perte de performances en mode développement. L’outil fait ce qu’il promet, et vaut réellement son prix ! Le plugin JRebel pour maven fait exactement ce qu’on attend de lui en générant automatiquement le fichier rebel.xml qui s’occupe de la magie.

Quel est le problème alors ?

Bien que JRebel soit un outil génial, il y a un peu trop de magie à l’intérieur et, dans certains cas particuliers, il se peut que ça ne marche pas tout à fait comme attendu. Dans mon cas, j’ai une application web assez classique divisée en plusieurs modules :

  • une application web (war)
  • un module ejb (jar)
  • d’autres modules non impliqués dans mon problème

La web application inclut, dans son dossier WEB-INF/lib, l’artifact ejb-client de mon module ejb. Pour être clair, l’artifact ejb-client est généralement le jar contenant les interfaces publiées permettant l’utilisation des ejb par les modules clients.

Le problème que j’ai eu était que la magie de JRebel entraînait le rechargemenet de trop de classes. En fait, JRebel rechargeait des classes qui n’étaient même pas dans mon artifact ejb-client. Mon container d’application (Glassfish 3.x) n’aimait pas trop ce comportement. J’ai donc ouvert un sujet sur le forum de ZeroTurnAround où j’ai eu une réponse me disant de trouver un moyen d’exclure les fichiers que je ne voulais pas voir rechargés dans mon module ejb-client.

J’ai donc fouiné dans maven-ejb-plugin, mais je n’ai rien trouvé permettant de renommer un fichier dans l’artifact ejb-client. Je n’ai pas non plus trouvé de paramètre spécifique à passer à JRebel pour lui spécifier quels noms de fichier il doit monitorer pour trouver sa configuration.
Continue reading

Récupérer la révision déployée d’une application à l’aide de Maven

Cet article n’a pas été traduit, veuillez trouver ci-dessous sa version anglaise

With our modern version control systems, we could assume we know for every single release we make the exact source code revision that corresponds. But, in the hurry of a bug found by your dear clients (or your product owner),  you can’t find the corresponding tag in your VCS, it will make the whole patch process really difficult. You will have to find the exact revision, extract it and debug to patch (or backport an existing patch).

I will explain a little trick to make the find the revision thing a lot easier (I am assuming you’re using maven to build your projects) : maven-buildnumber-plugin

Continue reading