Il y a 14 ans -
Temps de lecture 4 minutes
Refactorisation de bases de données avec Liquibase
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.
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
Publié par Emmanuel Servent
Emmanuel a rejoint Xebia en 2008 après quatre années passées à Unilog. Il associe les compétences techniques de l'écosystème Java à une prise de responsabilités sur l'encadrement d'équipes. Il tire son expérience des nombreux projets délicats rencontrés autant par le niveau d'exigence de l'application que par les délais à respecter.
Commentaire
4 réponses pour " Refactorisation de bases de données avec Liquibase "
Comments are closed.
Published by Waddle , Il y a 14 ans
Bonjour,
Il s’agit en effet d’un outil intéressant. Toutefois, passer par du XML, même avec la complétion d’un IDE, me semble bien plus verbeux et fastidieux.
Dans le cas d’une base unique partagée par tous les développeurs, l’apport de ce genre d’outil me semble très limité par rapport à une bonne utilisation du gestionnaire de sources (après tout, un sql n’est que le source de la base de données) : mise à jour du fichier de création de la base de données, tagging d’une version du projet incluant donc le modèle objet et le SQL. S’il ne s’agit que d’économiser un mail invitant les équipes à mettre à jour les sources…
Dans le cas d’une base de données par développeur, l’intérêt est plus significatif, mais cette approche est vraiment peu avantageuse et surtout dangereuse (configuration de la BDD, multiples versions sur le poste de développement, produits multiples, etc.) si bien qu’à titre personnel je ne l’ai jamais mise en place. Pour ce qui est des jeux de tests qui se « telescoperaient », si par là vous entendez que les tests des uns influence les tests des autres, pourquoi ne pas tout simplement passer par une base hsql pour les tests ? Cela permet en plus de tester le script de création par la même occasion.
Pour finir, je dirais qu’une base de données n’évolue qu’occasionnelement durant un projet, même dans un projet agile. J’entends par là qu’elle ne change pas tous les matins.
Je reste dubitatif donc, mais excellent article au demeurant, comme d’habitude :-)
a+
Published by Emmanuel , Il y a 14 ans
Bonjour,
Merci pour ce commentaire qui lance le débat.
La solution « la plus simple » est toujours une bonne solution. La plupart des projets utilisent des scripts SQL et s’en sortent bien.
Toutefois, il ne faut pas voir Liquibase comme un outil juste pour le développement et qui exécute du SQL. Il fait beaucoup plus de choses: suivi des modifications (auteur, date, etc.), rollback, génération de documentation, génération de diff. Il peut servir pour les livraisons dans les différents environnements, etc.
Pour ce qui est de la dangerosité d’une base par développeur, je suis assez d’accord, mais ça s’impose par moment.
Personnelement, je préfère travailler avec des fichires XML qu’avec des scripts SQL (rapidement illisibles). Les fichiers XML sont certes plus verbeux, mais sa structure facilite la lecture. Des balises qui indiquent le code de rollback, c’est très pratique. Et il est facile de vérifier que la modif et son rollback ont bien été écrites (malheureusement, ce n’est pas toujours le cas!).
D’expérience, les bases de données évolue toujours beaucoup durant le cycle d’un projet. Mais si ce n’est pas le cas, Liquibase présente évidemment moins d’interêt.
On peut se dire aussi « un outil de plus, un outil de trop? », mais l’avantage de Liquibase est qu’il est simple et peu invasif.
Il demande un peu d’investissement pour bien le prendre en main, comme tous les nouveaux outils, mais derrière, il facilite vraiment la gestion de la base de données.
Emmanuel.
Published by pse , Il y a 14 ans
Ca semble intéressant en effet.
Pour réagir au commentaire précédent :
– si on peut travailler sur un projet dont le modèle de données évolue à chaque version (ajout de tables, colonnes, …). C’est notre cas :-)
– on gère bien nos scripts SQL dans SVN, mais reste la problématique des patchs : si tu changes ton schéma, il te faut écrire un patch pour upgrader tes bases. Donc soit tu dupliques tes changements SQL entre le patch et le schéma complet, soit tu utilises un outil capable de faire un diff entre 2 schémas, soit tu utilises un outil de ce genre pour centraliser les mises à jour dans un autre format.
A voir.
Published by Robert , Il y a 14 ans
Ca me fait terriblement penser au script db:migrate que l’on trouve dans Rails. A la différence pres du format (code ruby au lieu d’xml), il s’agit de décrire les différentes migrations (rajout de colonnes, tables, changement de format, etc…) de la BD avec la possibilité de rejouer, revenir en arriere, etc… un peu comme liquibase.