Après les fêtes et les divers excès en tout genre, et pour commencer cette nouvelle année en légèreté, je voudrais vous parler des moyens de notifier les développeurs qu’un build a échoué sur le serveur d’intégration continue. On connaît le traditionnel mail, les très pratiques flux rss ou encore la messagerie instantanée, un peu plus rare. En voici quelques autres qui pourront vous amuser et probablement aussi faire adhérer quelques développeurs récalcitrants…
Suite à l’annonce faite sur TSS et aux nombreux commentaires en faveur de cet IDE, j’ai voulu l’essayer et voir ce qu’il avait à m’offrir par rapport à Eclipse. J’ai déjà eu l’occasion de m’en servir durant un an chez Club Internet en 2005 (la version 5.0 à l’époque) et j’en garde un assez bon souvenir, malgré quelques manques. Aujourd’hui, où en sommes nous ?
Qui utilise (utilisait) toujours commons-logging dans son application croyant bien faire ? Et qui parmi ceux-là s’est déjà heurté aux classloaders un peu vicieux de certains serveurs d’applications, Websphere notamment ? A tous ceux-là, ce billet est pour vous…
Si vous étiez au fin fond de l’Amazonie ou dans le Larzac ce 11 novembre, vous avez une excuse pour avoir loupé le rachat de G2One par SpringSource. Effectivement, nombreuses sont les annonces de ce rachat :
Sachant que Grails est déjà basé sur Spring, on ne peut que supposer un renforcement de ce duo et pourquoi pas la simplification de Spring MVC ? Concernant Groovy, nous verrons probablement apparaître un lien avec Spring Batch, afin de simplifier encore l’écriture de batchs… l’avenir nous le dira mais Spring continue son bonhomme de chemin.
Qui sera le prochain ? Personnellement, je verrai bien un framework Ajax (javascript & widgets) pour parfaire un peu nos interfaces (http://grails.org/Ajax ?).
En tout cas, félicitations à G2One (et à Guillaume, que je salue) qui en moins d’un an a réussi à se faire racheter par un gros poisson. À demain aux Rencontres Spring pour de nouvelles news !
 |
On entend souvent ici ou là des plaintes quant à la qualité et la quantité de documentation sur Maven. Je pense qu’Apache peut effectivement fournir des efforts, ainsi que tous les plugins mais globalement, on va dans le bon sens : |
- Les Guides Maven, fournissent un bon point de départ à Maven
- L’ebook Better Build with Maven, écrit par Jason Van Zyl en personne, et Vincent Massol, qui au delà de l’utilisation simple de l’outil décrit comment réaliser un plugin, comment migrer un projet vers Maven (la fameuse “mavenisation”), travailler en équipe avec Maven…
- L’ebook Maven Definitive Guide, aussi publié chez Oreilly et un poil plus récent, décortique Maven en long, en large et en travers. Tout y passe, jusqu’au plugin m2eclipse en passant par le repository manager Nexus. Tout y est décrit et illustré par des exemples… en un mot, la référence venu de Sonatype (dont Jason Van Zyl est CTO).
Avec environ 1000 pages de documentation sur Maven, rien que dans ces 2 livres, vous n’avez plus d’excuses pour vous y mettre !
Octo a publié récemment un nouveau livre blanc, disons pour le coup white paper puisqu’il est en anglais, sur le thème de la productivité des développements java : “12 conseils pour booster votre productivité avec une usine de développement”. N’ayant pas participé à cet ouvrage, je reviens dessus et donne mes impressions sur la productivité ET la qualité des développements.
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…
Que signifie intégration continue performante ?
L’intégration continue est une pratique de développement logiciel visant à intégrer au plus tôt le code de chacun des développeurs d’une équipe. Les bénéfices attendus sont nombreux : gain de temps pour l’intégration, détection des anomalies au fur et à mesure, application livrable à tout instant… Vous trouverez de nombreuses références sur cette pratique, notamment une présentation de Martin Fowler.
Et que vient faire la performance dans tout ça ? Plusieurs significations possibles :
- La performance du serveur d’intégration continue en lui-même
- La performance des développeurs, disons plutôt leur productivité, grâce à l’intégration continue.
- Et enfin, la performance de l’entreprise qui met en œuvre l’intégration continue (logiciels de qualité, livrables à chaque instant)
Analyse des différents critères
J’ai publié récemment sur le blog d’Octo la dernière partie de mon article sur l’intégration continue performante. Vous pourrez donc lire cet article aux adresses suivantes :
- Performance du serveur d’intégration continue
- Build incassable
- Industrialisation et interaction avec la production
Si vous avez besoin d’accéder à plusieurs bases de données SQL Server via votre application JEE et le tout bien sûr dans une même transaction, voici les différentes actions à entreprendre pour que cela fonctionne.
