Est-ce que nos outils de packaging actuels peuvent déployer nos applications?

Dans cet article, je souhaite comparer l’automatisation du déploiement au plus connu des processus automatiques du développement logiciel : le packaging de l’application. En simplifiant, le processus de packaging part du code source pour le transformer en code exécutable. La façon la plus simple pour créer ce code est d’utiliser un script shell qui lance le compilateur, mais ce processus a beaucoup mûri. Grâce à des outils comme Make, cité précédemment, mais aussi à Ant et Maven, l’utilisateur peut spécifier de manière très détaillée tout le processus. Prenons l’exemple de Maven, la plupart des projets n’ont plus besoin de scripter quoique soit. Le fichier POM décrit les composants du projet, les plugins utilisés, et la façon de packager l’application. Et en ce moment même, de nouveaux outils font leur apparition, comme Gradle, qui offre encore un peu plus de flexibilité.

Mais ces outils nous permettent-ils de faire du déploiement automatique? Dans un billet précédent, mon collègue Robert van Loghem a expliqué en quoi le déploiement est un processus complexe qui inclut un certain nombre d’étapes comme l’installation des EAR/WAR, la configuration des datasources et le redémarrage des serveurs.
Bien que Wikipedia inclut la fonction de déploiement vers des systèmes en production, lorsqu’il définit l’automatisation du packaging, les outils actuels n’ont pas intégré ces concepts de packages de déploiement (i.e. les livrables), les environnements cibles (test, recette, production, etc.) ou la modification des valeurs selon l’environnement. En réalité, ils n’ont pas de connaissances liées aux middlewares sur lesquels on déploie et ne proposeront certainement jamais des scenarii de déploiement. Au final, ce qu’offrent ces outils, c’est le moyen de scripter, bien connu des développeurs, et de stocker ces scripts avec les sources à installer. Cela amène irrémédiablement à de nombreux scripts « maison » pour automatiser les déploiements.

Mais ce n’est pas tellement surprenant. Dans Wikipedia, les pré-requis d’un système d’automatisation ne mentionnent pas le Déploiement. Un système de déploiement automatique a pour objectif de déployer du code exécutable sur un environnement cible, alors que le système d’automatisation du packaging ne fait que produire ce code exécutable.

Les pré-requis nécessaires pour que notre outil déploie

Voici une liste de pré-requis que devrait satisfaire un outil de déploiement automatique :

• Avoir nativement les concepts de base du déploiement : packages, environnements, lien entre les middlewares, etc.
• Support inclus pour les middlewares principaux avec une possibilité de l’étendre.
• Support inclus pour les scenarii courants de déploiement avec un moyen de les personnaliser.
• Proposer une séparation des rôles : les développeurs livrent le projet, un groupe d’administrateur définit les environnements et un autre groupe déploie l’application, etc.
• Supporter une charge croissante d’environnements avec plusieurs applications et de nombreux utilisateurs.
• Être capable de faire des déploiements multi-plateformes : des environnements complexes peuvent s’étendre sur de multiples systèmes d’opération et versions.

Les outils d’automatisation de packaging ne répondent pas à ces pré-requis et vouloir les étendre ne fera que complexifier leur utilisation sans pour autant faciliter convenablement les déploiements.
Cela explique l’émergence d’outils de déploiement automatique, qui ont dépassé les anciens outils de scripts « maison ».

Que l’on soit bien d’accord, les outils de déploiement automatique ne remplacent pas les outils d’automatisation des packages. Mais les deux ont leur place dans le paysage des livraisons d’applications. Les outils de packaging produisent le code exécutable et les outils de déploiements s’assurent de rendre ce code disponible pour les utilisateurs finaux !

Dans le prochain article de cette série, nous expliquerons en quoi le déploiement automatique est différent du mécanisme de gestion des livraisons de nouvelles versions.

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.

Livrer une nouvelle version est plus important que le premier déploiement !

Voici quelques raisons qui peuvent vous convaincre de porter plus d’attention à une nouvelle livraison:

• Les mises à jour sont plus fréquentes qu’un déploiement initial. ;-)
• Les mises à jour en production ont lieu alors que les utilisateurs sont déjà en train d’utiliser l’application ; il est préférable que cette dernière reste accessible pendant le déploiement ou, au pire, que la coupure soit la plus brève possible.
• Si une mise à jour échoue, l’ancienne version doit toujours être réinstallable.
• Et le fait qu’une mise à jour soit « routinière », peut tromper la vigilance des différentes personnes, responsables du déploiement. Il faut se méfier de l’excès de confiance. Lorsqu’une application est déployée pour la première fois, chacun est très attentif : les développeurs, les administrateurs des différents composants, les architectes, les responsables de projet, les utilisateurs, etc. Donc, quand un problème arrive, il est traité très rapidement. En revanche, si on souhaite déployer la version 2.1.54 un vendredi après-midi, c’est là que tout peut aller de travers.

En résumé, la mise à jour d’une application est complexe, et être concentré permet de diminuer les risques d’échec.

A présent, partons du scénario initial lorsque l’application est déployée. Ce scénario comprenait un fichier EAR, quelques fichiers statiques (images, css, etc.) et des scripts SQL.
Comment allons-nous mettre à jour cette application pour passer en v1.1 ? Pour simplifier, nous imaginons qu’il n’y a pas eu de changements sur le schéma de base de données entre v1.0 et v1.1.
Deux solutions sont possibles : soit nous mettons à jour juste ce qui est nécessaire, il s’agit alors d’un déploiement incrémental, soit nous supprimons la totalité de v1.0 et déployons proprement v1.1, et dans ce cas on fait un redéploiement complet.

Etapes nécessaires à chaque scénario

Si on choisit de simplement mettre à jour, voici les tâches à accomplir :

1. Supprimer le contenu statique v1.0 du serveur web.
2. Arrêter l’application v1.0.
3. Supprimer l’application v1.0.
4. Déployer l’application v1.1 à partir du fichier EAR.
5. Démarrer l’application v1.1.
6. Copier le contenu statique v1.1 sur le serveur web.

Et un redéploiement complet ressemble à ceci :

1. Arrêter le serveur web.
2. Supprimer le contenu statique v1.0 du serveur web.
3. Supprimer la configuration v1.0 du serveur web.
4. Arrêter le serveur d’applications.
5. Supprimer l’application v1.0.
6. Supprimer la configuration du serveur d’applications nécessaire à v1.0 (source de données, queues, etc.).
7. Créer la configuration du serveur d’applications pour v1.1.
8. Déployer l’application v1.1 à partir du fichier EAR.
9. Démarrer le serveur d’applications.
10. Créer la configuration v1.1 du serveur web.
11. Copier le contenu statique v1.1 sur le serveur web.
12. Démarrer le serveur web.

Si on compare les deux scénarii, on note aisément le nombre de différences :

• Le serveur web est arrêté au début et démarré seulement à la toute fin (étape 1 et 12).
• La configuration du serveur web est supprimée avant d’être recréée (étape 3 et 10).
• Au lieu de simplement arrêter puis démarrer l’application, le serveur d’applications complet est arrêté et démarré (étape 4 et 9).
• La configuration du serveur d’applications est elle aussi supprimée puis recréée (étape 6 et 7).

En supprimant puis recréant la configuration du serveur web et du serveur d’applications, nous avons la certitude de connaitre exactement le résultat qu’on obtiendra. En effet, si des changements ont eu lieu dans la configuration qui n’ont pas été notés, ils seront supprimés et non recréés. Pour ce faire, il faut arrêter les serveurs avant de les redémarrer à la toute fin du déploiement. Par contre, cela rend l’application indisponible, mais vous savez de toutes façons qu’il faudra bientôt mettre en place un cluster pour avoir une haute disponibilité, n’est-ce pas ? ;-)

L’autre point intéressant de ce scénario se trouve entre les étapes 7 et 12. Vous aurez certainement noté qu’elles correspondent exactement au scénario du déploiement initial de votre application. La petite différence se situe au niveau des étapes de création du schéma de la base de données. On peut enfin noter que les étapes 1 à 6 permettent de désinstaller complètement l’application.

Résumons maintenant les avantages et inconvénients des deux scénarii.

Du pour et du contre

Dans le cas du déploiement incrémental, on peut retenir les points suivants :

• Pour : Le déploiement incrémental s’exécute très vite car il fait le strict minimum.
• Contre : Le déploiement incrémental laisse éventuellement des traces de modifications manuelles. Ce point est problématique car la configuration a pu être changée de manière « magique » et sûrement non documentée pour que l’application fonctionne. Si vous décidez de migrer sur un autre serveur, vous oublierez probablement ces petites retouches. Et par-dessus tout, nous pouvons imaginer que si cela a été fait sur un des serveurs, et bien … je vous laisse compléter la phrase. :-)
• Pour : Le déploiement incrémental ne touche pas aux systèmes qui sont normalement OK. Mais encore une fois, si vous craignez de toucher votre système parce que ça pourrait ne plus fonctionner du tout, vous avez du travail. Il faut avoir suffisamment confiance dans les composants de votre environnement pour ne pas avoir peur de faire un changement, de redémarrer le serveur et enfin de prier pour que ça re-fonctionne correctement.
• Contre : Il est plus difficile de faire un retour arrière avec un déploiement incrémental. Pour chaque déploiement incrémental, il est nécessaire de décrire le scénario de retour arrière. En effet, comme le précédent déploiement était aussi incrémental, on ne peut donc pas le relancer. Sans scénario de retour arrière, la seule façon de revenir à v1.3 est de faire un déploiement « propre » de v1.0 est de déployer successivement v1.1, v1.2 et enfin v1.3.

A présent, voyons un peu ce que le redéploiement complet apporte comme solutions mais aussi comme difficultés :

• Pour : Le redéploiement complet efface toutes modifications manuelles, ne laissant que la configuration « bien » documentée en place.
• Pour : Le redéploiement complet est reproductible et prévisible. Grâce aux procédures qui sont systématiquement les mêmes, il n’y a aucune importance à connaitre ni la partie du produit qui a changé, ni l’état actuel de l’environnement cible. Ca sera toujours le même résultat.
• Pour : Le redéploiement complet permet d’avoir une stratégie de retour arrière extrêmement simple. Quand le déploiement d’une nouvelle version échoue, ou que la nouvelle application ne fonctionne pas, il suffit de déployer la version précédente.
• Contre : Conserver l’application disponible pendant le déroulement d’un redéploiement complet est une affaire plus délicate que pour un déploiement incrémental. Pour avoir une application en haute disponibilité, il est indispensable de configurer un cluster.
• Contre : Un redéploiement complet peut s’exécuter lentement si l’environnement cible n’est pas assez rapide, car le nombre d’opérations de configuration est important.

Déploiement incrémental, plus sûr que le redéploiement complet ?

Pour ma part, même si le redéploiement complet est parfois plus difficile et plus long à mettre en œuvre, le fait qu’il soit prévisible et reproductible est un avantage décisif qui fait passer les inconvénients au second plan. Le déploiement incrémental peut sembler être une approche plus simple et plus rapide pour déployer des mises à jour, mais vous sacrifiez ce qui est essentiel pour un scénario de déploiement, le processus de retour arrière. L’unique cas où le déploiement incrémental est indispensable, c’est lorsqu’on met à jour une base de données. Dans tous les autres, il est recommandé d’utiliser le redéploiement complet pour appliquer des changements.

Traduction libre du billet « Incremental deployments vs. full redeployments » publié par Vincent Partington sur blog.xebia.com.

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. »

Rendre l’application accessible à l’utilisateur final

Avant de parler des différentes étapes du déploiement, il est important de comprendre quel est l’objectif d’un déploiement. De façon élémentaire, le but d’un déploiement est de « rendre une application, dans une version donnée, disponible pour les utilisateurs finaux ». En d’autres termes, l’utilisateur ouvre son navigateur, tape www.app.com et voit l’application fonctionner.

Alors, que faut-il faire pour qu’une application fonctionne? Pour comprendre les composantes du déploiement, le plus simple est de suivre la requête depuis le navigateur de l’utilisateur à travers tous les composants matériels et logiciels par lesquels elle transite.
« La destination de la requête est tout d’abord résolue en s’adressant à un serveur DNS (ou à un mécanisme équivalent). La requête est alors routée vers sa destination ; elle est filtrée par un premier firewall, arrive sur le serveur HTTP chargé de la répartition de charge, traverse un nouveau firewall, atteint le serveur d’applications puis enfin l’application à proprement parler, exécutée sur le serveur, qui elle-même interroge une base de données pour récupérer les informations demandées par l’utilisateur. »
Sur cet exemple simple, il y a au moins 5 composants en action pour rendre disponible l’application ; nous devons non seulement configurer ces 5 composants mais aussi y placer certaines données et s’assurer au besoin qu’ils (re-)démarrent dans un ordre correct.

Voici typiquement les étapes nécessaires au premier déploiement d’une telle application sur un environnement de production :

• (a) Exécuter les ordres SQL de création de tables sur la base de données
• (b) Configurer la source de données JDBC dans le serveur d’applications
• (c) Configurer les ports HTTP et les Virtual Hosts dans le serveur d’applications pour que l’application soit accessible par les requêtes HTTP
• (d) Installer l’application sur le serveur d’applications
• (e) Démarrer l’application
• (f) Configurer le firewall, en ouvrant les ports utiles à la communication entre le serveur HTTP et le serveur d’applications
• (g) Configurer le serveur HTTP, pour router vers le serveur d’applications les requêtes arrivant sur www.app.com et qui ne se terminent pas, par exemple, par .js, .html, .jpg
• (h) Déposer le contenu HTML statique (fichiers js, fichiers css, images, etc.) sur le serveur HTTP
• (i) (re-)Démarrer le serveur HTTP pour prendre en compte la nouvelle configuration
• (j) Configurer le firewall externe, pour permettre les accès de www.app.com vers le bon serveur HTTP

Bien sûr, dans un environnement plus complexe, on ajoute quelques étapes à la liste. Par exemple, dans un environnement clusterisé avec haute disponibilité, tout doit être fait au moins deux fois. Pour les déploiements de versions ultérieures de la même application, certaines étapes pourront de surcroît être négligées.

Des tâches nombreuses et variées

Les étapes décrites dans la section précédentes permettent de « mettre à disposition des utilisateurs » une application à l’architecture élémentaire. D’une façon plus générale, on peut distinguer plusieurs grandes catégories d’opérations à réaliser pour finaliser un déploiement :

• Installer l’application (Étape d)
  C’est la partie principale du déploiement, où la logique métier est installée sur le serveur, le plus souvent sous la forme d’un fichier EAR ou WAR.
• Configurer les ressources externes (Étape b)
  L’application peut avoir besoin d’interagir avec d’autres systèmes, comme une base de données, un mainframe ou un middleware de message. Les ressources externes sont le plus souvent utilisées par l’application pour obtenir ou diffuser des données. L’accès à ces ressources est généralement configuré au niveau du serveur d’applications.
• Configurer les composants intermédiaires (Étape a, c, f, g, h, j)
  Ce sont les composants qui permettent d’atteindre l’application, et de l’exécuter (par exemple, un cluster de serveurs d’applications, des instances de serveurs HTTP, des firewalls, etc.).
• Démarrer/Arrêter les composants (Étape e, i)
  Pour s’assurer que chaque composant fonctionne correctement, il peut être nécessaire de le (re-)démarrer.
• Et respecter l’ordre dans les points précédents

Pour être sûr que l’application démarre correctement, sans erreurs, un certain ordre doit être maintenu. Exemple : Si vous installez l’application (Étape d) et la démarrez avant d’avoir configuré la source de données (Étape b), l’application risque de ne pas se lancer correctement. Ceci devient encore plus important lorsque vous déployez une nouvelle version de votre application dans un environnement clusterisé.

Il y a une catégorie supplémentaire pour les organisations qui valident leurs applications successivement sur plusieurs environnements (Développement, Test, Intégration, Production) :

• Configurer l’application installée sur des environnements différents
  Un déploiement doit assurer la configuration spécifique à l’environnement. Exemple : Quand vous installez une application sur l’environnement de développement, il faut récupérer les données de la base de développement. De la même façon, pour l’environnement de tests, il est nécessaire d’avoir les données de tests et ainsi de suite.

L’EAR, la partie émergée de l’iceberg

Beaucoup pensent qu’installer un EAR sur un serveur d’applications équivaut à déployer l’application. Bien sûr, le bouton dans la console d’administration indique : « Déployer l’application », mais il ne s’agit que de la partie concernant le serveur d’applications à proprement parler ; cette vision étroite du déploiement n’est généralement opérationnelle que sur un environnement simplifié, comme celui de développement ou sur le poste de travail du développeur. Dès qu’une application doit être installée sur un environnement plus complexe, cette vision ne suffit plus et il devient nécessaire de réaliser un grand nombre d’opérations complémentaires pour véritablement « mettre l’application à disposition des utilisateurs ».

Parce que de ce point de vue le déploiement n’est pas une opération triviale, beaucoup cherchent à l’automatiser.
Exécuter manuellement toutes les étapes est en effet à la fois complexe et risqué, particulièrement sur les environnements les plus critiques. Et ce, d’autant plus que, souvent, les responsabilités et les gouvernances de chaque module de l’infrastructure reposent entre les mains de personnes, d’équipes, voire de départements différents.
Malheureusement, cet effort d’automatisation aboutit souvent à un ou plusieurs jeux de scripts à la gouvernance floue et dont le coût de maintenance semble souvent prohibitif. Les solutions du marché n’abordent souvent qu’un sous-ensemble de la problématique (on pense à Phurnace ou BuildForge, qui restent concentrés sur le serveur d’applications, ou à d’autres solutions qui sont souvent de simples ordonnanceurs de scripts).
Avec les serveurs d’intégration continue, on peut mettre en œuvre des déploiements automatiques, qui permettent de tester la chaîne complète de la compilation jusqu’aux tests de charge (cf. Build Pipelines). Et si l’on veut aller encore plus loin, c’est-à-dire déployer automatiquement sur l’environnement de production, on peut se pencher sur le logiciel DeployIt, développé par mes collègues Hollandais.

Je parlerai, plus en détail, dans un prochain article du déploiement automatique et nous pourrons déterminer par nous-même si c’est une solution « Insane » comme le pense le livre blanc Enterprise CI Maturity Model de la société anthillpro ou une solution réelle pour améliorer la fiabilité comme le pense DeployIt.

Samedi matin, j’ai assisté à la session sur la gestion de source dans un environnement distribué. Après une mise au point sur la différence entre gestion de configuration et gestion de source, nous avons entamé la discussion sur l’outil très utilisé dans le développement Open Source dénommé GIT. Cet outil fonctionne en mode décentralisé : il n’y a pas un unique serveur de sources, mais chaque développeur fonctionne à la fois en mode serveur et en mode client. Le développeur peut, par exemple, versionner très souvent ses sources sur son serveur local, mais décider de ne valider ses changements qu’en une seule fois sur le serveur de référence (il peut même signer sa validation !).
Le cas d’un projet partagé entre la France et l’Australie m’a particulièrement intéressé. Le responsable avait mis en place un serveur intermédiaire GIT sur chaque site pour éviter les échanges réseau trop nombreux avec un serveur central. Une synchronisation régulière permettait aux deux sites d’être à jour. Il s’était rendu compte au bout d’un certain temps que cela était en réalité inutile, car la qualité du réseau faisait qu’on pouvait se permettre de n’avoir qu’un seul serveur. En revanche, si cela est peut-être vrai pour l’Australie, ce ne l’est pas forcément pour tous les pays.
Avec GIT, chaque copie du repository est une nouvelle branche ; un développeur en local, c’est une branche. Le fonctionnement des branches est un vrai casse-tête pour des outils comme Subversion, et cette approche propose finalement un peu de simplicité. Mais pour le moment, les serveurs d’Intégration Continue ne font pas la différence entre modes centralisé et décentralisé. Rien n’est proposé aujourd’hui pour mieux profiter d’un monde distribué…

Après un ravitaillement en café et jus d’orange, j’ai suivi Vincent Massol, de XWiki pour savoir comment améliorer notre façon de faire une release avec Maven. Arnaud Heritier faisait parti de la session et après une présentation du processus pour XWiki, ils ont démarré le codage d’une extension au plugin dependency. L’objectif était d’ajouter un goal pour récupérer les différences entre les versions des dépendances entre deux releases. Il faudra être attentif aux prochaines sorties de ce plugin, il y aura peut-être une nouvelle fonction.
Le constat, finalement, était qu’il y avait encore beaucoup d’étapes manuelles lors de la release d’une version et qu’à part développer ses propres MOJOs, Maven était assez loin du compte. Mais ça avance comme le montre le plugin versions, dont Arnaud Heritier nous a vanté les mérites.

L’après-midi, trois sessions nous attendaient mais je souhaite ne parler que de la dernière sur la configuration et le déploiement, les autres étant déjà traitées sur différents blogs. Un problème récurrent se pose sur chaque projet, celui de la modification des valeurs selon l’environnement sur lequel on déploie. On utilise, par exemple, des fichiers de propriétés qui sont remplacés au moment du packaging. Si on s’est trompé dans les propriétés ou si la valeur n’est connue que de la personne qui déploie, il faut dézipper le fichier, changer la valeur et refaire le package. Bonjour la galère !
Deux ingénieurs de ThoughtWorks nous ont présenté leur petit dernier : Escape. Sous ce nom très commun se cache une application Java dans laquelle on peut sauvegarder les valeurs des propriétés de chaque application dans un environnement donné. Ces valeurs peuvent être cryptées. Pour y accéder, une simple interface REST permet d’interroger la base et de récupérer la valeur : l’url http://mymachine:8080/environnements/dev/citcon/city, par exemple, renvoie la valeur de city pour l’environnement de dev sur l’application citcon. Je trouve ce projet simple et efficace pour améliorer la gestion des propriétés de nos applications. La mise en œuvre demandera un peu d’effort pour disposer d’un serveur central mais cela en vaut certainement la peine pour s’affranchir de cette partie de la configuration.

La conférence s’est terminée par un tour des participants sur leur « AA moment » (ie. ce qu’ils ont préférés!) et une distribution de livres sur l’intégration continue.
J’en ai gagné un, écrit par Paul M. Duvall, qui était juste à côté de moi, et me l’a dédicacé. Et c’est aussi ce qui rendait cette journée franchement sympathique et réussie; mon « AA moment » a été de mettre enfin un visage sur des auteurs de blogs ou des contributeurs open source, et surtout pouvoir converser de visu.

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.

Problèmes posés par la gestion des bases de données

Lorsqu’un projet démarre, on se demande souvent si l’on doit installer une base de données par développeur ou une base commune pour tous.
Sur des projets de taille réduite, une base peut suffire et une personne est désignée pour centraliser les changements et éviter ainsi des problèmes de redondance, d’incohérence, etc. Mais dans ce cas-là, dès qu’un changement est effectué, tout le monde doit impérativement mettre à jour le modèle objet sinon il court le risque de ne plus pouvoir lancer l’application. Par ailleurs, les jeux de tests de chaque développeur peuvent « se télescoper » ce qui peut faire perdre beaucoup de temps.
Sur des projets plus importants, il est préférable d’avoir une base par développeur, ce qui cause d’autres difficultés, telles que les répercutions des changements d’un développeur à l’autre ou encore une intégration plus laborieuse.
Se pose aussi la question suivante : comment va-t-on tracer les changements successifs ? Le plus courant reste d’écrire un fichier d’update SQL mais ce n’est pas fait systématiquement pendant les développements et ça manque de structure (au sens XML) et ça pas de signification propre. Par exemple, rien ne permet rapidement de différencier dans un script, le code qui applique les changements de celui qui les rollback (à part les commentaires !); ou les actions comme « Renommer » se traduisent par un DROP COLUMN / ADD COLUMN, ce qui fait perdre le sens de l’action.
Cette dernière question amène à s’en poser d’autres :

• comment versionner les changements effectués sur une base de données ?
• comment appliquer les changements ? Entre développeurs, mais aussi lorsqu’on passe en intégration, puis en recette, etc. Pour le moment, cette étape prend du temps, que ce soit en amont si on décide de packager correctement les changements, ou en aval lorsqu’il s’agit de dérouler les scripts.

Voilà en quelques phrases les multiples difficultés rencontrées lorsqu’on souhaite refactoriser une base de données.
Regardons à présent ce qu’un outil comme Liquibase peut faire pour nous accompagner dans ce travail délicat.

Refactorisation de bases de données avec Liquibase

Liquibase est un outil qui peut s’intégrer dans un projet (Ant, Maven, etc.) ou se lancer en mode standalone directement en ligne de commande (jar).
Son objectif est de faciliter les modifications apportées à une base de données. Il est particulièrement pratique dans des projets ayant adoptés une méthodologie Agile, car les changements sont nombreux, fréquents et importants.
Le développeur enregistre dans un fichier XML (changelogs.xml), les différentes refactorisations qu’il souhaite effectuer (création d’une nouvelle table, renommage d’un champ, insertion de données, etc.). Ensuite, il suffit de lancer Liquibase en lui donnant les paramètres de connexion à la base de données et le fichier changelogs.xml. Liquibase applique ces modifications et les trace dans une table.
Les fichiers changelogs.xml sont versionnés dans le gestionnaire de sources, et sont considérés comme n’importe quelle autre ressource du projet. La base de données est alors complètement intégrée au cycle de développement.

Après cette brève présentation de Liquibase, intéressons-nous aux caractéristiques principales de cet outil.

Caractéristiques et fonctionnalités principales

Liquibase est Open Source diffusé sous licence LGPL. Ce projet Open Source est actif, la dernière version (1.8.1) est sortie en octobre 2008 et sa road map montre qu’il veut aller encore plus loin. Il supporte un grand nombre de bases de données (> 10) et propose plus de 30 refactorisations possibles. Et pour certaines, il sait même faire un roll back (Ex: renommer une colonne).
Les changements peuvent être regroupés dans un changeset, ce qui permet de conserver un sens et une cohérence aux modifications.
On peut également n’exécuter des changements que sous certaines conditions, ou selon un certain profil d’exécution (utile pour les jeux de tests par exemple).

On peut noter également que Liquibase n’est pas juste « braqué » vers la refactorisation de la base de données, il offre d’autres fonctionnalit