Flyway / Liquibase des outils simples à utiliser

 

En tant que développeur on doit tous à un moment donné, créer des scripts SQL : que ce soit pour la structure de la base ou pour les données. Or quand il s’agit de la base on ne pense pas à versionner comme on le ferait pour du code. Actuellement, il existe de nombreuses solutions qui ont chacune leurs avantages et leurs inconvénients, personnellement je vais présenter Flyway et Liquibase, car j’ai pu les utiliser dans un contexte métier différent.

C’est quoi exactement ?

Ce sont des framework open-source de migration et de versionnage de base.

Quel est l’intérêt ?

L’intérêt des outils de gestions de versions, tels que GIT ou SVN, ne sont plus à prouver. De la même manière flyway et liquibase viennent répondre à ce besoin pour les bases de données. De plus, ils supportent beaucoup de bases de données : Oracle, Mysql, PostgreSql, H2…

Comment ça marche pour flyway ?

Flyway ajoute une table technique de métadonnées :

  • shema_version : elle contient toutes les modifications effectuées par Flyway

Il scanne le classpath et trouve les scripts de migrations. Que ce soit en java ou en sql.

Il applique les scripts non versionnés et la table schema_version contient toutes les traces.

Et comment ça marche pour liquibase ?

Liquibase ajoute deux tables techniques :

  • databasechangelog : elle contient toutes les modifications effectués par liquibase
  • databasechangeloglock : elle contient le nom de la machine qui est en train de passer des scripts liquibase. Cela permet de ne pas avoir deux exécutions simultanées

Via un fichier db.changelog-master dont le format peut changer (xml, json…) qui contient la liste des modifications à exécuter, il va exécuter les changeset non présent dans la table databasechangelog.

Alors ils sont différents ?

On peut voir que le fonctionnement est assez similaire pour les deux librairies

Mise en pratique

Intégration dans un projet

Flyway et liquibase s'intègre facilement via : Spring, maven gradle, ant ou ligne de commande.

Tout est bien expliqué via le site de flyway : https://flywaydb.org/getstarted/

Pour liquibase, il faut chercher un peu plus mais cela reste accessible sur la documentation : http://www.liquibase.org/documentation/index.html

Création de scripts Flyway

Les scripts peuvent être écrits en SQL ou en java. Chaque script correspond à une version unique.

Ils doivent se trouver dans le package db.migration.

Le nommage est très important :

 

Toutes les conventions de nommages sont configurables (package de base, préfixe et suffixe des scripts).

Création de scripts Liquibase

Les fichiers “changelog” peuvent être écrit au format : XML, YAML, JSON, SQL ainsi que d’autres formats. Ils contiennent toujours la notion de changeset avec un identifiant unique, souvent une description ainsi qu’un auteur afin de savoir qui a lancé le script.

Concernant la structure et la mise en place il faut suivre ce qu’indique liquibase dans ses meilleures pratiques.

Conclusion

Ce sont des outils simple, pratique et facile à mettre en place. Ils sont assez similaires dans la façon de penser. D’autant plus si votre équipe utilise une méthode agile et que votre base de données subit des évolutions régulières à chaque sprint.

Il faut savoir que de nombreux développeurs ne sont pas à l’aise avec ces outils et oublie qu’il ne faut pas modifier des fichiers existants. Ces fichiers ont été tracés et ne doivent plus être modifié. Donc n’oubliez pas cela si vous utilisez un de ces outils. On ajoute des fichiers, même si c’est pour les supprimer !

En terme d’utilisation, je préfère liquibase, je trouve qu’il est plus facile à mettre en place et à utiliser par rapport à flyway ; surtout il est plus permissif lorsque l’on développe. Faire du reverse engineering est également beaucoup plus simple avec liquibase.

Pour aller plus loin

 https://github.com/flyway

 https://github.com/liquibase

 

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *