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 | test | 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 | test | 2018-04-21 13:42:48.226561
2 | 2 | add alerts | SQL | V2__add_alerts.sql | -1104212433 | test | 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.