Flyway to Hell

Vous versionnez votre code, pourquoi pas votre base de données ?

Pourquoi ?

Prenons un exemple courant. Une équipe de cinq développeurs avec chacun une machine de développement. Sur ces machines, une base de données. Ajoutons à cela un serveur d’intégration et un serveur de production avec leur propre base de données. La problématique est de gérer les différentes versions de l’application sur toutes les machines.

Concernant le code, rien de plus simple. Nous utilisons tous les jours des outils de gestion de versions. Qu’en est-il de la base de données ?

Ce sont souvent des scripts SQL échangés et exécutés manuellement. En plus de ne pas être très pratique, des questions se posent : quels scripts ont déjà été appliqués et lesquels restent-ils à appliquer ?

Flyway répond à ces questions en permettant de gérer les différentes versions de la base de données. Plus besoin d’y aller à la main, Flyway gère tout ça pour vous.

D’autres outils existent et la page d’accueil de Flyway résume bien l’existant. Ce comparatif permet de se faire une idée des différentes fonctionnalités supportées par chaque outil. De notre coté, nous avons fait le choix d’utiliser Flyway pour sa simplicité d’utilisation. C’est de cet outil dont nous parlerons dans la suite.

Comment ça marche ?

Flyway repose sur des scripts de migration écrits soit en SQL, soit directement en Java, chaque script possédant un numéro de version unique, un titre et éventuellement une description.

Lors de la première migration, Flyway va créer une table correspondant à la liste des scripts exécutés avec leur version associée. Ainsi, le dernier enregistrement de cette table correspond à la version de la base de données.

À chaque migration, Flyway va lister tous les scripts de migration disponibles et exécuter tous ceux dont la version est supérieure à la version de la base de données, le tout dans l’ordre croissant des versions.

Les scripts de migration

Flyway privilégie la convention plutôt que la configuration. Ainsi, les fichiers de migration doivent se trouver dans le classpath et plus précisément dans le package db.migration. Il est toujours possible de configurer cela.

Les nom des fichiers de migrations doivent suivre un format particulier pour que Flyway puisse les utiliser :

  • La lettre ‘V’,
  • La version représentée par des chiffres et des lettres séparés par des underscores ou des points.

En option, on peut rajouter :

  • Deux underscores,
  • La description du script.

SQL

L’utilisation de scripts SQL permet d’utiliser la syntaxe SQL ainsi que les spécificités de nombreux systèmes de gestion de base de données. Ceci est adapté aux modifications simples des données ou du schéma.

Java

Les classes de migration Java doivent implémenter JavaMigration et donc la méthode migrate. La migration se fait à partir d’un objet JdbcTemplate de Spring. Ce mode est plus adapté aux migrations lourdes.

1
2
3
4
5
6
7
8
9
10
11
12
import com.googlecode.flyway.core.migration.java.JavaMigration;
import org.springframework.jdbc.core.JdbcTemplate;

/**
 * Example of a Java-based migration.
 */

public class V1_2__Another_user implements JavaMigration {
     @Override
     protected void migrate(JdbcTemplate jdbcTemplate) throws Exception {
          // Du code
     }
}

Effectuer une migration

Plusieurs possibilités sont offertes pour lancer une migration.

Command-line

Flyway fournit un script permettant de gérer la version de la base de données directement depuis une console. Vous pouvez ainsi initialiser la base de données :

1
$ ./flyway.sh init

Effectuer une migration :

1
$ ./flyway.sh migrate

D’autres commandes permettent d’afficher la version actuelle ou la liste des scripts exécutés. Les informations de connexion à la base de données sont par défaut lues dans le fichier conf/flyway.properties mais il est possible d’utiliser un autre fichier de configuration avec l’option -configFile=somewhere/else/maConfig.properties.

Maven

Un plugin maven est aussi fourni. Il suffit d’ajouter dans le pom.xml :

1
2
3
4
5
6
7
8
<plugin>
     <groupId>com.googlecode.flyway</groupId>
     <artifactId>flyway-maven-plugin</artifactId>
     <version>1.6.1</version>
     <configuration>
          ....
     </configuration>
</plugin>

On peut donc lancer les commandes avec maven :

1
2
$ mvn flyway:init
$ mvn flyway:migrate

Ansi que flyway:status, flyway:history, …

Java

Il est aussi possible de lancer la migration directement en java. Pour cela, rien de plus simple :

1
2
3
4
5
6
7
8
9
import com.googlecode.flyway.core.Flyway;

...

Flyway flyway = new Flyway();
flyway.setDataSource(myDataSource);
flyway.migrate();
flyway.status();
...

Spring

Encore plus simplement, Flyway s’intègre dans Spring et permet de mettre à jour la base de données si besoin au déploiement de l’application. Il suffit de rajouter dans le fichier de configuration de spring :

1
2
3
4
5
6
7
<bean id="flyway" init-method="migrate">
     <property name="dataSource" ref="myDataSource"/>
</bean>

<bean id="sessionFactory" depends-on="flyway">
     ...
</bean>

Les limites

Flyway est très pratique en développement lorsque la base de données est amenée à être modifiée régulièrement, notamment à chaque sprint lorsqu’on utilise une méthode Agile.

Par contre, Flyway n’est pas magique et ne permet pas de faire des migrations complexes. Par exemple, il n’est pas possible de faire des commits au milieu d’un script de migration pour faire un point de sauvegarde.

La migration de base de données n’est pas une opération triviale que Flyway peut résoudre. Il n’est donc pas à utiliser en production.

Aller plus loin

Google code du projet Flyway : http://code.google.com/p/flyway/
JavaDoc : http://wiki.flyway.googlecode.com/hg/javadoc/index.html

VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share
Ce contenu a été publié dans Java, Outils, avec comme mot(s)-clef(s) , , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire