Productivité

Il s'agit d'un problème récurrent lorsque l'on développe une application JEE et pour lequel on n'est jamais vraiment au point : "comment gérer la configuration de mon application sur les différents environnements ?" Pourtant on dispose de tous les ingrédients pour y parvenir, et Maven n'est pas forcément le seul...

Dans la première partie de ce billet, je mentionnais divers solutions (bonnes pratiques, outils) pour optimiser les performances du serveur d'intégration continue et faire face au nombre croissant de projets gérés par ce serveur.
Dans cette seconde partie, j'aborde un sujet récurrent lorsque l'on fait de l'intégration continue : les erreurs (compilation, tests, packaging) sur le serveur. Effectivement, mieux vaut découvrir ces erreurs en continue sur le serveur plutôt que la veille de la livraison. Mais, ne serait-ce pas mieux si on pouvait simplement les éviter ?

Alors que l'intégration continue fait son bonhomme de chemin dans les développements en entreprise, plusieurs constats peuvent être fait.

La généralisation de cette pratique n'est pas égale chez tout le monde :

• Chez certains, des usines de développement (plus communément appelées Software Factory) fleurissent par ci par là sous l'impulsion de développeurs chevronnés ou d'expert techniques mais se cantonnent la plupart du temps au développement d'un projet. Résultat : pas d'uniformisation (utilisation d'outils redondants, de méthodologies variées...) mais les équipes sont contentes de leurs usines car elles rendent le service attendu.
  

• Chez d'autres, une seule usine d'entreprise existe (ou est censé exister). Résultat : l'usine croule sous le nombre de projets (configurés plus ou moins anarchiquement), la durée des builds augmente et les équipes finissent par remonter une petite usine dans leur coin pour pallier à la lenteur du serveur.
  

• Au milieu de ça, il y a ceux qui sont dans le premier cas et qui veulent industrialiser. La plupart du temps, ils n'ont pas les moyens nécessaires (support aux équipes, serveur suffisamment puissant) et surtout ils manquent cruellement d'appui des supérieurs et/ou de la production. Résultat : l'usine est peu ou pas utilisée, les projets ne sachant parfois même pas qu'il en existe une centralisée.
  

• Et enfin à l'extrême, il y ceux qui n'en ont pas du tout. Résultat : ils se passent d'une pratique, qui, si elle est mise en œuvre correctement, apporte énormément tant sur la productivité que sur la qualité des applications.
  

L'industrialisation de cette pratique amène donc les limitations suivantes (pas vraiment nouvelles [1]) :

• Le serveur d'intégration ne tient pas la charge lorsque de nombreuses applications y sont construites.
  

• Malgré tous les apports de l'intégration continue, il arrive encore trop régulièrement de casser le build si un développeur peu rigoureux omet de publier un fichier, en ajoute un qui ne compile pas ou qui ne passe pas les tests... bref l'intégration se fait encore trop tardivement !
  

• L'intégration continue ne fait pas partie intégrante du cycle développement / production d'applications, en tout cas pas suffisamment pour être exploité au mieux par toutes les équipes projets.

Ce billet (1er d'une série de 3) traitera des performances des serveurs d'intégration continue.

Après avoir tapé pour la 42 millième fois -Dmaven.test.skip=true après ma commande mvn, j'en ai eu raz le bol. J'ai donc regardé rapidement la doc de zsh pour mettre un minimum de complétion sur cette commande. Voilà le résultat : il faut ajouter un fichier nommé _mvn, exécutable, dans /usr/local/zsh/4.3.4/functions Fichier : #compdef mvn _wanted maven expl 'maven2' compadd pre-clean clean post-clean validate generate-sources process-sources generate-resources process-resources compile process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile process-test-classes test prepare-package package pre-integration-test integration-test post-integration-test verify install deploy pre-site…