Dans les principes de l’agilité, l’un des ingrédients essentiels est d’avoir une boucle de retour rapide. En tant que développeur, vous êtes donc profondément convaincu par l’intégration continue. Seulement, vous en avez assez de cette situation :

À tout moment de la journée peut retentir cette fameuse phrase: « Mais qui a (encore) cassé le build ??« 
Il y a alors plusieurs stratégies d’équipe :

• ce n’est pas grave, cela arrive tout le temps. Cela va bien finir par passer au vert !
• celui qui casse paie et corrige le problème
• l’ensemble de l’équipe se sent concerné, une personne se dévoue pour enquêter et corriger le problème.

La règle d’or : aucune modification ne peut être apportée sur le code tant que l’intégrité du projet n’est pas restaurée.
Une fois le problème résolu, au Scrum Master de créer un système à base de croissants à offrir, de cagnottes à remplir, d’avatars à afficher ou encore de lance-missile USB pour que cela se produise le moins souvent possible.
Une carte Xebia Essentials illustre cette démarche : NO BLAME BUT NO MERCY.

Vient alors l’idée de s’assurer que le commit que je me prépare à envoyer correspond un minimum aux critères de validation de l’intégration continue. Le processus de validation doit être automatisé et en mode bac-à-sable (son exécution ne doit perturber personne).

Lire la suite de cet article »

Répondant à la demande, le 31 janvier nous rééditerons la soirée des 13 et 20 octobre derniers !

La saison est au Continuous Delivery ! Venez découvrir comment automatiser le déploiement d’une application java web typique sur des serveurs Tomcat via une usine GitHub/Jenkins/Nexus.

Nous verrons plusieurs techniques de déploiement, de la plus simple à la plus sophistiquée :

1. déploiement sur Tomcat avec des commandes shell lancées par Jenkins au lieu de les lancer à la main ;
2. utilisation du tomcat-maven-plugin avec les conseils d’Olivier Lamy, lead developer du plugin et committer Tomcat ;
3. homogénéisation des déploiements du dev à la prod avec Jenkins associé à Rundeck pour gérer des commandes shell. Vincent Behar, committer Jenkins et ‘owner’ du jenkins-rundeck-plugin nous présentera cet outil Open Source en vogue chez les OPS ;
4. DeployIt : l’outil intégré d’automatisation des déploiements made in Xebia.

Pour avoir plus de détails sur le déroulement de l’atelier et pour vous inscrire, nous vous invitons à utiliser la page dédiée sur Eventbrite.

Pour déployer une application sur un serveur Tomcat distant, nous avons vu précédemment comment utiliser Apache Tomcat Maven Plugin. Nous pouvons aussi utiliser un script. Cette solution plus élaborée est certainement plus proche des solutions d’exploitation existantes aujourd’hui dans nos entreprises. 

Dans l’esprit DevOps, il faut avoir un mode de déploiement le plus tôt possible identique à celui de la production. L’approche par script convient ainsi à un maximum d’environnements possibles (du test jusqu’à la production).
Pour ce faire, le script sera placé sur le serveur distant et exécuté à distance.

Le but de cet article est de vous proposer une solution pour déployer une application web sur un serveur Tomcat distant à chaque commit sur votre repository. Pour cela, nous allons utiliser le plugin Remote SSH pour Jenkins.

Lire la suite de cet article »

Les 13 et 20 octobre derniers a eu lieu le deuxième Tech Event Xebia avec, cette fois, comme sujet le Déploiement Continu sur Tomcat avec Jenkins, Rundeck et Deployit. Pour l’occasion nous avons eu la collaboration spéciale de deux guest stars :

• Olivier Lamy, architecte chez Talend, membre de la fondation Apache et committer sur Tomcat et sur Jenkins
• Vincent Behar, ingénieur Java à Exalead, owner du plugin Rundeck pour Jenkins et cofondateur de Paris Devops, 

Merci à eux pour leur participation à la préparation de l’atelier ainsi qu’à sa présentation.

Flickr est l’exemple le plus évoqué à l’heure actuelle de déploiement continu. Il existe bien d’autres exemples connus comme Outbrain, Wealthfront ou Etsy. Même si le nombre d’entreprises qui arrivent à ce niveau de maturité est encore faible, il est possible qu’à l’avenir cette méthode devienne une technique courante dans les projets avec la progression de l’agilité. Son implémentation oblige, en effet, à accomplir quelques principes du manifeste agile, dont par exemple :

Ainsi qu’à en pousser d’autres :

Lire la suite de cet article »

Vous avez peut-être eu l’obsession de voir « maven » en train de télécharger vos propres artefacts à partir de son repository central. Du moins vous vous êtes sûrement posé la question : mon projet est mavenisé, open source, sur une forge publique (github, googlecode, etc.) et il est destiné à être utilisé par le plus grand nombre ; pourquoi ne pas le publier sur le Maven Central Repository (http://repo1.maven.org) ?

Au lieu de penser à ouvrir votre Nexus sur Internet ou encore à créer votre propre repository sur Google Code ou autre, nous vous proposons de directement déployer sur le Maven Central Repository, ce qui, en plus de vous épargner l’installation d’un repository, facilitera l’utilisation de votre artefact.

Le but de ce billet est de décrire la marche à suivre pour la publication d’un artefact en passant par le repository de Sonatype. Ce dernier étant un repository approuvé pour tout projet OSS comme c’est le cas du repository Apache (pour les projets Apache) et celui du Codehaus (pour les projets Codehaus). Le fait de passer par Sonatype vous garantit d’une part, un processus de validation structurant qui impose un ensemble de points de contrôle (licence, copyright, traçabilité, etc.) augmentant ainsi la qualité des métadonnées, et d’autre part une synchronisation rapide avec le Maven Central Repository.

Il s’agit également de vous faire profiter de notre expérience sur le sujet avec le déploiement de quelques artefacts tels que mindmap-maven-plugin, xebia-management-extras, xebia-spring-security-extras et xebia-servlet-extras.

Lire la suite de cet article »

Comme vous l’avez peut-être constaté dans vos applications d’entreprise, les dépendances des modules sont parfois difficiles à appréhender, de par leur nombre et la complexité des relations.

Encore plus si vous vous retrouvez face à un chantier de refactoring important qui touche à votre application en sa globalité (refonte du modèle métier, éclatement de modules, restructuration des couches logicielles, migration de framework, externalisation des traitements communs en aspect, …) ; assurer la réussite d’un tel chantier s’avère généralement une tâche difficile : vous avez beau essayé de pousser l’étude d’impact au bout, les surprises sont toujours au rendez-vous.

Garder un œil sur l’application en phase de transformation implique systématiquement une prise de « snapshots » réguliers des dépendances entre modules ; cela vous permettra sans doute de savoir rapidement si vous êtes sur la bonne voie, ou si un « break – rethink to avoid worse » est nécessaire.

C’est dans cette optique que le Mind Mapping s’impose afin de fournir une vue documentaire visuelle facilement exploitable des dépendances des modules ; vous permettant ainsi de contrôler la tendance du projet et d’éviter toute apparition de dépendance cyclique directe ou indirecte (transitive), du moins la faire disparaître assez rapidement si elle est déjà là.

De ce fait, on s’aperçoit que cette approche a plus de valeur ajoutée pour le Lead technique ou encore l’architecte de l’équipe de développement que pour le développeur. Quant à ce dernier, et si besoin (on ne s’amuse pas à faire des « mvn dependency:tree » tous les jours), il pourrait rester fidèle aux outils qui viennent accompagner son IDE, que ce soit sous forme de plugin (Jdepend, byecycle, M2Eclipse avec Dependency graph view et Dependency Hierarchy view, …) ou encore en standalone (JDepend, mvn dependency:tree, …).

Dans cet article, on s’intéresse particulièrement aux projets « mavénisés ». La démarche consiste, pour un module donné, à produire un artefact pouvant être exploité par un outil open source de Mind Mapping. L’idée est donc de développer un simple plugin maven en charge de générer un fichier au format attendu pour l’outil. Il existe plusieurs logiciels open source de Mind Mapping à savoir FreeMind, FreePlane (un dérivé de FreeMind), Xmind, etc. Le choix est fait sur FreePlane qui traite des fichiers de type « .mm ».

Lire la suite de cet article »

Selenium regroupe une suite d’outils permettant de tester des applications web. Tout comme les tests unitaires, Selenium permet notamment de vérifier la non-régression d’une application et est un gage de qualité supplémentaire. Bien que la création des tests Selenium soit relativement simple, automatiser leur exécution sur un serveur d’intégration continue reste complexe à mettre en œuvre. Je vous propose une solution avec l’outil de build Maven. Disposant de nombreux plugins, comme SQL, Failsafe, Jetty et Selenium, Maven permet la mise en place d’une automatisation satisfaisante. Cette solution peut servir aussi aux tests d’intégration.

Lire la suite de cet article »

En ce beau matin d’hiver, me voilà bien décidé à effectuer un peu de ménage sur notre projet. Ma cible d’aujourd’hui : la chasse aux warnings.

Grosso modo, j’observe qu’il y a 3 types de warning :

• imports inutilisés (60%)
• unchecked casts (30%)
• variables ou méthodes private non utilisées (10%)

Je prends mon bâton de pèlerin et je nettoie. Cependant, je me rends bien compte que ces warnings sont pour la majorité des erreurs d’inattention qui pourraient être facilement évitées.

A quoi bon nettoyer, si c’est pour se retrouver dans la même situation dans trois mois ? Donc, en plus de ma maintenance corrective, je pars également à la recherche d’une action préventive.

Première idée évidente, configurer Eclipse pour que celui-ci effectue ce genre de nettoyage lors d’une sauvegarde d’un fichier. Facile, il suffit de paramétrer ceci dans Properties -> Java Editor -> Save Actions (Plus de détails ici).

Cependant, à quoi bon le faire uniquement sur mon Eclipse ? Quel intérêt, si les autres membres de l’équipe ne bénéficient pas eux aussi de la même configuration ? Comment faire en sorte que ma configuration soit facilement partagée avec les autres ?

Le projet étant un projet maven, le maven-eclipse-plugin semble offrir la solution.

Lire la suite de cet article »

Depuis le traditionnel outil make, introduit en 1977 pour livrer en production un logiciel, plusieurs étapes, de la construction du logiciel au processus de livraison, ont été automatisées. En réalité, être professionnel lorsqu’on parle de développer des logiciels, c’est, a minima, savoir automatiser la compilation et les tests en intégration continue. Mais un autre sujet progresse aussi dans le domaine de la gestion du cycle de vie des applications (Application Lifecycle Management – ALM), il s’agit de l’automatisation des déploiements. Cette progression est en partie due à nos environnements (serveurs d’application, ESB, EAI, etc.) qui sont de plus en plus complexes et étendus. Le nombre croissant de nouvelles versions d’une application, demandées par le business moderne, et le fait que le déploiement doit être suffisamment fiable pour ne pas risquer d’interrompre un service en ligne sont deux raisons supplémentaires qui poussent à s’intéresser à cette question. Ajoutez à cela que les infrastructures en cloud gagnent un peu plus de terrain chaque jour, et vous conviendrez que l’on a encore un long chemin, à la fois motivant et intéressant, à parcourir.

Lire la suite de cet article »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Cloudbees propose Hudson en Software as a Service
• JBoss met en avant les performances de HornetQ

SOA

• Lancement de vFabric au VMworld 2010 : Spring in the cloud

Le coin de la technique

• GWT 2.1 sera Maven compliant
• OAuth : pas le protocole d’authentification ultime ?
• Ruby on Rails 3 est sorti du bois, JRuby l’attendait au bar

Evènements de notre communauté en France et à l’étranger

• Jug Summer Camp 2010 – La Rochelle

Lire la suite de cet article »