Flyway, la base de données tranquille

Posté le 21 avril 2018

Je n’aime pas …

interrompre le travail des autres et vice-versa. Quand je dois livrer un applicatif avec une base de données, pourquoi devrais-je emmerder le DBA pour passer un pauvre script sql parce que j’ai modifié ma base ? Le jour de la mise en prod, je dois encore lui demander de rester ? Comment je gère les versions de la base en cohérence avec mon code?

La solution : Flyway

On code tout aujourd’hui : l’infrastucture, le réseau… alors pourquoi pas la base de données? Les avantages sont simples :

  • Gestion des versions
  • Migration automatique à chaque lancement
  • Ajout/Suppression de données pour des tests unitaires
  • Cohésion code applicatif / base de données

Configuration de la base de données

J’utilise une base postgres pour mon tutorial mais mettez celle qui vous plait

fichier flyway.conf

flyway.url=jdbc:postgresql://localhost:5432/testdb
flyway.user=test
flyway.password=myTestPassword
flyway.locations=filesystem:./db

Premier pas

Créons notre premier fichier V1__init.sql

Le nom du fichier est important :

  • première lettre V
  • ensuite la version avec des _ : 1_0 ou 1 ou 1_0_1
  • une séparation par un double _
  • le nom de la version
CREATE TABLE users (
  userID SERIAL PRIMARY KEY,
  firstname varchar(100) NOT NULL,
  lastname varchar(100) NOT NULL,
  username varchar(100) NOT NULL,
  password chkpass NOT NULL
);

Lançons flyway

> flyway -configFile="flyway.conf" migrate
Successfully validated 1 migration (execution time 00:00.010s)
Creating Schema History table: "public"."flyway_schema_history"
Current version of schema "public": << Empty Schema >>
Migrating schema "public" to version 1 - Init
Successfully applied 1 migration to schema "public" (execution time 00:00.109s)

Regardons la base de données maintenant : Surprise ! Deux tables !

  • Notre table users
  • La table flyway_schema_history

Regardons là de plus près (version raccourcie)

rank | version | description | type |    script    |  checksum   | installed_by |        installed_on        |
-----+---------+-------------+------+--------------+-------------+--------------+----------------------------
   1 | 1       | Init        | SQL  | V1__Init.sql | -1595535795 | survyv       | 2018-04-21 13:42:48.226561 |

On peut ainsi suivre les évolutions.

On fait le deuxième pas ?
Fichier : V2__add_alerts.sql

CREATE TABLE alerts (
  alertID SERIAL PRIMARY KEY,
  longitude float NOT NULL,
  latitude float NOT NULL,
  dataMessage bytea
);

On relance flyway : même ligne de commande que tout à l’heure.

La table flyway_schema_history (version raccourcie)

rank | version | description | type |       script       |  checksum   | installed_by |        installed_on       
-----+---------+-------------+------+--------------------+-------------+--------------+--------------------------
   1 | 1       | Init        | SQL  | V1__Init.sql       | -1595535795 | survyv       | 2018-04-21 13:42:48.226561
   2 | 2       | add alerts  | SQL  | V2__add_alerts.sql | -1104212433 | survyv       | 2018-04-21 13:44:58.524486

Gestion des Versions

Sous flyway, plusieurs actions sont possibles :

  • Migrate : migre 1 à n schéma(s)
  • Undo : revenir une version en arrière (version Pro donc je n’en parle pas)
  • Clean : bon, vous avez compris son principe
  • Validate : Vérifie la cohérence entre vos fichiers SQL et votre base

Faisons un petit tour :

Migrate

On l’a déjà utilisé précédemment : On valide un schéma, on monte de version. C’est exactement ce que nous avons fait sur les deux premiers pas.
La notation est avec la lettre V, comme aux premiers pas

  • V1__init.sql
  • V2__add_alerts.sql

N.B. On utilise la lettre U pour la partie Undo (version payante)

Clean

Tout est dans le titre, un bon delete de toute la structure, on repart à vide. Evidemment, on évite en production.

Validate

Rien de transcendant : une vérification de la cohérence.. jamais utilisé pour ma part.

> flyway -configFile="conf/flyway.conf" validate
Successfully validated 2 migrations (execution time 00:00.017s)

Conclusion

Il existe des librairies pour insérer directement dans votre code : scala, java. Vous l’insérez directement dans votre code : au démarrage, votre base se met à jour. J’ai utilisé ici des créations de tables mais on pourrait insérer des données pour des tests unitaires pour simplement des données de références.

Est-ce qu’on tue le travail du DBA ? Franchement, quelle est est la valeur ajoutée d’un DBA de passer un script sql? Aucun ! C’est même une perte de temps pour eux. Utilisez ce temps pour travailler avec eux pour gérer les performances, optimiser les bases mais libérez les de ces tâches.