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 ?

(Lire la suite…)

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.

(Lire la suite…)

Grande soirée GROOVY et GRAILS le 9 septempre 2008 au Paris JUG

Guillaume Laforge (G2ONE) viendra présenter GROOVY, le langage dynamique pour la machine virtuelle JAVA.
Quant à moi, j’aurais le plaisir de vous présenter GRAILS, le killer framework d’applications web Groovy & Java du moment!

S’appuyant massivement sur le concept « Convention Over Configuration », GRAILS permet d’être très rapidement opérationel et maximiser l’apport de valeur métier en minimisant le code et les configurations techniques. Du prototype rapide à la mise en production, venez voir comment cette solution open-source favorise l’innovation métier et garantie une intégration sans rupture dans le système d’information.

Programme et inscriptions, c’est ici.

Venez nombreux !

Fabrice Robini

Bonjour à tous,

Un mois de juin relativement calme dans l’ensemble de la communauté. Etant moi-même en vacances une bonne partie du mois, mes analyses des évolutions sur les plugins sont relativement succinctes. Le mois prochain j’espère pouvoir vous annoncer la release d’archiva 1.1 puisque aujourd’hui a lieu une journée spéciale où un maximum de développeurs de notre équipe travaillent conjointement pour résoudre les bugs restant.

En gras les releases « majeures » (non alpha, beta, RC et autres versions pas encore considérées comme abouties).
En italique les annonces « périmées » par une annonce plus récente.

(Lire la suite…)

Avec un peu de retard, voici les slides et surtout le code utilisés lors de la session du 10 juin du ParisJUG.

(Lire la suite…)

L’intégration continue (connue aussi sous le nom de « build continu ») est l’une des pratiques agiles les plus populaires. C’est surement parce qu’il s’agit de l’une des plus simples à mettre en œuvre : on télécharge l’un des nombreux outils disponibles (Hudson, CruiseControl, Continuum, Bamboo….), on le fait pointer vers le référentiel de sources du projet (subversion, cvs …), et c’est parti : tel un métronome il préviendra l’équipe toutes les 10 minutes si le code présent dans le référentiel de sources du projet ne compile pas ou ne passe pas les tests automatisés.

Mais suffit-il d’avoir un tel outil installé pour pouvoir prétendre faire de l’intégration continue ?
Je pense que non.

(Lire la suite…)

Bonjour à tous,

Revoici la synthèse des news de la communauté Maven. Quelques contraintes m’ayant empêchées de rédiger celles du mois de février, vous retrouvez ici celles des deux derniers mois. Et comme en plus avril est déjà bien entamé, je vous livre les nouvelles de ce début de mois en plus.

En gras les releases « majeures » (non alpha, beta, RC et autres versions pas encore considérées comme abouties).
En italique les annonces « périmées » par une annonce plus récente.

(Lire la suite…)

GWT est un framework développé par Google permettant de réaliser des pages Web suivant la technologie AJAX. Ce framework propose de développer entièrement l’interface graphique à partir du langage Java.
Ce code est ensuite compilé en langage Javascript, pour être embarqué dans une application Web. GWT est composé d’une partie cliente, en Javascript, qui constitue l’IHM de l’application, elle communique avec une partie serveur développée en Java.

Pour autant, passé la découverte de cet excellent framework, une question se pose rapidement : Quels sont les bons patterns et designs de code à mettre en oeuvre avec ce framework ?
Partons d’un exemple, regardons les problèmes, et proposons une amélioration permettant de faire émerger un design cohérant.

(Lire la suite…)

Bonjour à tous,

Pas de grandes nouveautés pour un début d’année cadencé au rythme des releases des plugins.

(Lire la suite…)

Tout projet de développement implique des choix d’architecture. Quels patterns de code ? Quels outils de build ? Un projet innovant place ces question sur un axe temporel : les réponses adaptées ne sont pas les mêmes entre la 1ere itération et la 20ème itération. Une architecture « dynamique » permettra de maximiser la valeur apportée par une architecture applicative à un moment donné d’un projet.
(Lire la suite…)