Liquibase
Source control for your database
Liquibase
● L’existant
● Les problèmes rencontrés
● La solution : Liquibase
● Et après
● Questions
L’existant
L’existant
● Réalisation d’un schéma sous powerAMC
(MPD)
○ Permet de normaliser les relations
○ Partage du schéma via le référentiel (internes /
service stats / RAP)
○ Ajout des schémas dans confluence
L’existant
● Récupération des scripts SQL depuis
PowerAMC
○ Dans le meilleur des cas : génération de tous les
scripts si “from scratch”
○ Récupération de morceau de script via la
prévisualisation
L’existant
● Création des script pour la base H2
○ Permet de monter une base de données et de
charger un jeu de données à chaud pour la
réalisation des tests d’intégration
● Création des scripts pour la MEP
○ Ajout de ces scripts au document de MEP sous
confluence
Les problèmes rencontrés
Les problèmes rencontrés
● PowerAMC
○ Génération des scripts ok si “from scratch” mais
gestion des deltas très peu intuitive et aléatoire
○ Suivi des évolutions et des versions compliquées et
peu intuitive
Les problèmes rencontrés
● H2
○ Script de chargement à maintenir spécifiquement
pour les tests
○ Retravaille des scripts depuis PowerAMC
systématique
Les problèmes rencontrés
● Script pour la MEP
○ Demande une grande rigueur dans la maintenance
des scripts
○ Retour arrière presque jamais réalisé
○ Exécution manuelle uniquement
○ Partage et suivi des évolutions des scripts
laborieuses
La solution : Liquibase
La solution : Liquibase
● Langage XML pour décrire les scripts à
exécuter en base
○ Même langage de script quelque soit la base de
données (MySQL, H2, etc.)
○ Format arborescent pour une meilleur lisibilité des
blocs de chargement
La solution : Liquibase
La solution : Liquibase
● Permet de suivre les évolutions des scripts
via SVN
○ Utilisation d’outils connus et standards (SVN)
○ Meilleur suivi des évolutions des schémas
La solution : Liquibase
La solution : Liquibase
● Lancement des scripts au chargement de l’
application
○ Permet de faire des exécutions conditionnelles et
de prévoir des scripts de retour arrière
○ Intégration des scripts de chargement de la base de
données dans les livrables (WAR)
○ Un pas vers l’industrialisation des livrables
La solution : Liquibase
La solution : Liquibase
web.xml
applicationContext.xml
La solution : Liquibase
● Suivi des scripts déjà chargés directement
dans des tables spécifiques Liquibase
○ Création par Liquibase de deux tables : lock de
chargement, suivi des scripts
○ Tolérance au clustering
○ Possibilité de faire un reverse engineering sur l’
existant et de considéré les scripts obtenus déjà
exécutés
La solution : Liquibase
La solution : Liquibase
Et après
Et après
● Suppression des droits en écriture en
intégration et production
○ Oblige à la réalisation des scripts via liquibase pour
livraison en intégration
○ Permet de garantir le suivi des évolutions en base
de données
○ Fonctionnement par alter
Et après
● Un super-user connu par 3 personnes avec
les droits en écriture en secours
○ Permet de prévoir les cas ou Liquibase n’est pas
approprié
○ Permet d’intervenir en urgence sur des problèmes
de production
Et après
● Réalisation des scripts de chargement H2 à
l’aide de Liquibase
○ Plus de maintenance des scripts spécifiques H2 en
dehors des données de test
○ Une méthode, un seul type de fichier pour charger
les bases H2 et charger/mettre à jour les bases
MySQL
Et après
● Quelques limites
○ Chargement des scripts au démarrage des
applications => scripts à exécution relativement
rapide
○ Autres limites à découvrir
Et après
MISE EN PLACE ASAP !!!!
Questions ?

Liquibase

  • 1.
  • 2.
    Liquibase ● L’existant ● Lesproblèmes rencontrés ● La solution : Liquibase ● Et après ● Questions
  • 3.
  • 4.
    L’existant ● Réalisation d’unschéma sous powerAMC (MPD) ○ Permet de normaliser les relations ○ Partage du schéma via le référentiel (internes / service stats / RAP) ○ Ajout des schémas dans confluence
  • 5.
    L’existant ● Récupération desscripts SQL depuis PowerAMC ○ Dans le meilleur des cas : génération de tous les scripts si “from scratch” ○ Récupération de morceau de script via la prévisualisation
  • 6.
    L’existant ● Création desscript pour la base H2 ○ Permet de monter une base de données et de charger un jeu de données à chaud pour la réalisation des tests d’intégration ● Création des scripts pour la MEP ○ Ajout de ces scripts au document de MEP sous confluence
  • 7.
  • 8.
    Les problèmes rencontrés ●PowerAMC ○ Génération des scripts ok si “from scratch” mais gestion des deltas très peu intuitive et aléatoire ○ Suivi des évolutions et des versions compliquées et peu intuitive
  • 9.
    Les problèmes rencontrés ●H2 ○ Script de chargement à maintenir spécifiquement pour les tests ○ Retravaille des scripts depuis PowerAMC systématique
  • 10.
    Les problèmes rencontrés ●Script pour la MEP ○ Demande une grande rigueur dans la maintenance des scripts ○ Retour arrière presque jamais réalisé ○ Exécution manuelle uniquement ○ Partage et suivi des évolutions des scripts laborieuses
  • 11.
    La solution :Liquibase
  • 12.
    La solution :Liquibase ● Langage XML pour décrire les scripts à exécuter en base ○ Même langage de script quelque soit la base de données (MySQL, H2, etc.) ○ Format arborescent pour une meilleur lisibilité des blocs de chargement
  • 13.
    La solution :Liquibase
  • 14.
    La solution :Liquibase ● Permet de suivre les évolutions des scripts via SVN ○ Utilisation d’outils connus et standards (SVN) ○ Meilleur suivi des évolutions des schémas
  • 15.
    La solution :Liquibase
  • 16.
    La solution :Liquibase ● Lancement des scripts au chargement de l’ application ○ Permet de faire des exécutions conditionnelles et de prévoir des scripts de retour arrière ○ Intégration des scripts de chargement de la base de données dans les livrables (WAR) ○ Un pas vers l’industrialisation des livrables
  • 17.
    La solution :Liquibase
  • 18.
    La solution :Liquibase web.xml applicationContext.xml
  • 19.
    La solution :Liquibase ● Suivi des scripts déjà chargés directement dans des tables spécifiques Liquibase ○ Création par Liquibase de deux tables : lock de chargement, suivi des scripts ○ Tolérance au clustering ○ Possibilité de faire un reverse engineering sur l’ existant et de considéré les scripts obtenus déjà exécutés
  • 20.
    La solution :Liquibase
  • 21.
    La solution :Liquibase
  • 22.
  • 23.
    Et après ● Suppressiondes droits en écriture en intégration et production ○ Oblige à la réalisation des scripts via liquibase pour livraison en intégration ○ Permet de garantir le suivi des évolutions en base de données ○ Fonctionnement par alter
  • 24.
    Et après ● Unsuper-user connu par 3 personnes avec les droits en écriture en secours ○ Permet de prévoir les cas ou Liquibase n’est pas approprié ○ Permet d’intervenir en urgence sur des problèmes de production
  • 25.
    Et après ● Réalisationdes scripts de chargement H2 à l’aide de Liquibase ○ Plus de maintenance des scripts spécifiques H2 en dehors des données de test ○ Une méthode, un seul type de fichier pour charger les bases H2 et charger/mettre à jour les bases MySQL
  • 26.
    Et après ● Quelqueslimites ○ Chargement des scripts au démarrage des applications => scripts à exécution relativement rapide ○ Autres limites à découvrir
  • 27.
    Et après MISE ENPLACE ASAP !!!!
  • 28.