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 »

Dans un précédent article sur le déploiement, j’ai présenté l’ensemble des tâches à mettre en œuvre pour déployer une application Java dans un environnement d’entreprise. Le scénario décrivait étape après étape la configuration de chaque composant comme les serveurs web, les pare-feux, la base de données et les ressources externes JEE. Le point clé à retenir était que ces différentes configurations de composants avaient autant d’importance dans un déploiement que l’installation d’un fichier EAR ou WAR.

Mais voilà, comme on l’avait rapidement suggéré précédemment, il existe un scénario légèrement plus compliqué que celui décrit ci-dessus ; il s’agit du cas de mise à jour d’une application vers une nouvelle version. Bien que le déploiement initial d’une application soit forcément important, un certain nombre de raisons me fait penser que le déploiement d’une nouvelle version l’est encore plus.

Lire la suite de cet article »

Vous venez juste de boucler la première version de votre application, packagée par Maven. Vos intégrateurs ont préparé un environnement de recette et vous ont communiqué les informations de connexion à la console d’administration de votre serveur d’applications. Vous vous connectez, accédez aux fonctionnalités de déploiement et déployez le fichier EAR. Satisfait, vous démarrez votre navigateur pour vérifier que l’application tourne correctement. Mais quand vous essayez de charger la page, vous obtenez l’erreur DNS « Host not found ». C’est donc le moment d’appeler un ami – l’administrateur de cette obscure infrastructure, qu’on appellera Michel. Michel est bien sûr très heureux d’ajouter un enregistrement DNS qui va permettre d’aller sur le serveur Apache à partir de l’URL www.app-in-dev.com. « Quoi ! Un serveur Apache ? » vous exclamez vous, « Mais ça devrait pointer vers notre serveur d’applications, pas du tout vers un quelconque serveur HTTP ! ».

Michel, qui a l’habitude de ce genre d’exclamation vis-à-vis de l’organisation des réseaux d’entreprise, explique calmement que toutes les requêtes partant d’un navigateur doivent d’abord passer par un serveur HTTP avant d’être redirigées vers le serveur d’applications. « Il est donc aussi nécessaire de configurer Apache ! », dit-il. « Mais je développe une application Java, j’ai juste besoin de déployer sur un serveur d’applications et hop, terminé ! » répondez vous. Et Michel d’expliquer sur un ton très sérieux : « Écoute fiston, appuyer sur le bouton de déploiement de ta console d’administration est juste une petite étape parmi toutes celles qui permettent de réaliser un vrai déploiement. »

Lire la suite de cet article »

Le CITCON (prononcé « KITCON ») a eu lieu vendredi et samedi dernier à Paris, pour la session européenne 2009. Vendredi soir, après les présentations d’usage, l’open space a commencé par le remplissage du tableau des sessions par les fameux post-it. Pour rappel, les participants écrivent un thème sur un post-it et le collent n’importe où sur le tableau. C’est autour d’un verre, et entre deux discussions, qu’on vote et place les post-it dans les cases proposées pour chaque session.

Lire la suite de cet article »

Gérer les modifications d’une base de données est toujours une affaire délicate, que ce soit lors du développement d’une application, pendant le déroulement des tests unitaires et même lors du déploiement en production.
On observe un grand nombre de difficultés, en particulier dans les projets Agile, où les changements sur le modèle de données sont fréquents.
A l’heure actuelle, peu d’outils sont disponibles sur le marché et on pense rarement à les mettre en place sur nos projets. On passe par des solutions « maisons » avec toutes les difficultés que cela peut engendrer.

Tout d’abord, nous ferons un point sur les problèmes posés par la gestion des bases de données, puis nous verrons comment Liquibase, outils de refactorisation, peut nous aider à les surmonter.
Nous continuerons par la description de ses caractéristiques et fonctionnalités principales et par les différents moyens de l’exécuter.
Un petit exercice pour se familiariser avec cet outil viendra conclure ce billet.

Lire la suite de cet article »