Boostez la performance de vos développements

Les billets de la semaine dernière ont soulevé des réactions intéressantes : il semblerait que chez Responcia, notre « cycle de build » soit nettement plus rapide que dans la majorité des sociétés…

Tout d’abord, qu’entendons-nous par « cycle de build »? Proposons cette mesure : la durée entre…

1. La sauvegarde d’un fichier Java (ou JSP ou autre… Java étant généralement le pire cas)
2. Le test de l’application réalisée dans un navigateur Internet

Entre ces deux étapes, le fichier est compilé, l’application est « packagée », elle est ensuite déployée sur un serveur d’application, etc…

Pour avoir travaillé chez de nombreux clients, ce cycle peut parfois durer plusieurs minutes, voire plusieurs heures. Et de manière très surprenante, plus le client paye cher, plus cette durée a tendance à s’allonger…

Pour information, le cycle que nous venons d’étudier dure entre 2 et 4 secondes avec Responcia Developer Edition, et de manière générale on ne se rend même pas compte qu’un tel cycle existe. Voici les grands principes qui permettent cela :

1. Nous faisons attention à Maven. Nous utilisons le plugin Jetty de Maven, et sommes généralement en mode « offline » pour la gestion des dépendances. Et nous utilisons uniquement le respository central de Maven.
2. Nous avons du hardware spécifique. Cela a tendance à surprendre beaucoup de monde! Mais l’achat de ce disque dur SSD nous a permis de réduire par 3,5 la durée de la commande Maven « mvn -o clean package ». Pour 140€ TTC, le retour sur investissement est immédiat.
3. Nous utilisons Jetty : la vitesse de démarrage n’a rien à voir avec un Weblogic ou un Websphere. Par rapport à un Tomcat récent, le gain est plus minime, mais subsiste toujours (et nos tests de charge prouvent également qu’il tient mieux la charge en production).
4. Nous avons un IDE bien configuré : à la sauvegarde d’un fichier Java, le build est automatiquement lancé, sans passer par des commandes supplémentaires… Nous reparlerons bientôt sur ce blog du meilleur IDE Java existant, Intellij IDEA.
5. Nous utilisons Spring Security avec le filtre « remember me » (avec le persistent token, l’autre n’étant de toute manière pas bien sécurisé!). Ce qui fait que lorsque Jetty reboote, même si les sessions sont perdues, vous êtes automatiquement authentifié (un test amusant : cela marche même si l’on éteint Jetty et que l’on lance un Tomcat à la place!).
6. Nous n’avons pas de données en session utilisateur (cf. les principes REST, dont nous avons un peu parlé la semaine dernière). Ce qui évite d’avoir à cliquer plusieurs fois pour revenir sur la page que l’on teste.

Pour aller plus loin : il nous reste la possibilité d’utiliser JRebel ou tout simplement les fonctionnalités de Hotspot pour pouvoir changer du code Java à chaud. Cependant le cycle actuel est déjà tellement performant que ce n’est pas franchement la peine…

Enfin, terminons sur deux points importants : si sur votre projet,

1. le « build » prend plusieurs minutes, ou
2. si vous devez faire un build à chaque changement de JSP,

ce n’est pas normal!