1.
Gestion du changement et
bases de données, avec Liquibase
Viadeo Tech Days

2.
Programme
1. Gestion du changement et bases de données
2. Liquibase
3. Liquibase chez Viadeo

3.
Gestion du changement et Bases de données

4.
Gestion du changement et Bases de données
pourquoi ?
Le code est généralement directement lié à la base de données qui
lui sert de référentiel de persistance.
Suivre les changements du schéma de cette base et des données de
référence est donc rendu nécessaire
Le schéma de la base et les données de référence font partie intégrante du
code de l'application.

5.
Gestion du changement et Bases de données
les trois règles
Trois règles de bon sens :
1. NE JAMAIS UTILISER UN SERVEUR DE BASE DE DONNEES CENTRALISE
(PARTAGE) POUR LES PHASES DE DEVELOPPEMENT
2. TOUJOURS DISPOSER D'UNE SEULE SOURCE DE REFERENCE DU
SCHEMA
3. VERSIONNEZ TOUJOURS VOTRE SCHEMA DE BASE

6.
Gestion du changement et Bases de données
Règle n°1
NE JAMAIS UTILISER UN SERVEUR DE BASE DE DONNEES
CENTRALISE (PARTAGE) POUR LES PHASES DE
DEVELOPPEMENT
● Tentant, infrastructure simplifiée, les modifications de schéma se font directement sur la
base, qui sert de base de test et de développement. Les modifications sont
immédiatement visibles par toutes les équipes.
● Très mauvais pattern, rends impossible ou très compliqué le développement par
branches, par d'historisation des modifications, la base finit par devenir complexe et sale,
pas de validation possible des modifications des schéma.
● Les effets de bords ne sont pas maîtrisables, le développement à distance est rendu
difficile.
● Il devient impossible de remonter une base correspondant à un état donné du code

7.
Gestion du changement et Bases de données
Règle n°2
TOUJOURS DISPOSER D'UNE SEULE SOURCE DE
REFERENCE DU SCHEMA
Developpeur 1: C'est le moment de mettre l'application en test, est-ce que l'on copie la base de Thomas ou de Pierre ?
Developpeur 2: Huummmmmmmm, je ne sais plus trop laquelle est la plus à jour...
Developpeur 1: On est foutu...
● Tout le monde doit savoir où le schéma de la base se trouve, si possible accolé au
code (dans le système de gestion de version du code par exemple)
● Il doit être aisé de monter une nouvelle base à jour sur un nouvel environnement ou
de repartir d'une base fraîche après des tests, une expérimentation ou une branche
abandonnée
● Il doit être aisé de monter un nouvel environnement de travail, une nouvelle branche
de développement et de lui associer la base dans l'état attendu
● Le processus de mise à jour doit pouvoir créer une base depuis le départ ou de mettre
à jour une base existante vers un état donné

8.
Gestion du changement et Bases de données
Règle n°3
VERSIONNEZ TOUJOURS VOTRE SCHEMA DE BASE
● L'objectif est de suivre un processus maîtrisé et constant de mise à jour du schéma de la
base directement dépendant du processus de promotion du build, du développement à la
production en passant par les tests.
● Il doit être possible le plus facilement possible de remonter un état de base de données
correspondant à une version donnée du code applicatif, d'autant plus si l'entreprise
versionne son application à des fins de distribution :
○ si un client trouvé un bug sur le build 20121120 de votre appliccation vous devez être en
mesure de remonter un environnement de debug correspondant à cet état

9.
Gestion du changement et Bases de données
conclusion
Il ne viendrait à l'idée d'aucun développeur logiciel de ne pas gérer son code au
moyen d'un logiciel de suivi de version.
L'intégration du schéma des bases de données à un système de suivi de version
n'est pas un must-have et doit être pris en compte exactement de la même
manière que le code, avec le même niveau d'exigence et de qualité.
Le suivi des changements de la base de données en plus d'être efficacement pris en
compte doit l'être au plus proche du code puisque ce même code s'appuie
généralement directement sur la base de données et sur son schéma.
Intégrer ce mécanisme directement sur le système de gestion de version du
code est donc généralement une bonne idée.

10.
Gestion du changement et Bases de données
pour finir..
Martin Fowler Quote :
" A common mistake is not to include everything in the automated build. The build
should include getting the database schema out of the repository and firing it up in
the execution environment. I'll elaborate my earlier rule of thumb: anyone
should be able to bring in a virgin machine, check the sources out of the
repository, issue a single command, and have a running system on their
machine. "

11.
Gestion du changement avec Liquibase

12.
Gestion du changement avec Liquibase
source: http://www.liquibase.org/

13.
Gestion du changement avec Liquibase
features
● Over 30 built-in database refactorings
● Extensibility to create custom changes
● Update database to current version
● Rollback last X changes to database
● Rollback database changes to particular date/time
● Rollback database to "tag"
● SQL for Database Updates and Rollbacks can be saved for manual review
● "Contexts" for including/excluding change sets to execute
● Database diff report
● Database diff changelog generation
● Ability to create changelog to generate an existing database
● Database change documentation generation
● DBMS Check, user check, and SQL check preconditions
● Ability to split change log into multiple files for easier management
● Executable via command line, Ant, Maven, Servlet container, or Spring
● Support for 10 database systems
source: wikipedia

14.
Gestion du changement avec Liquibase
Changelogs/Changesets
source: http://www.liquibase.org/

15.
Gestion du changement avec Liquibase
migration tool
liquibase
--driver=com.mysql.jdbc.Driver
--classpath=/path/to/classes
--changeLogFile=com/example/db.changelog.xml
--url="jdbc:mysql://localhost/example"
--username=user
--password=asdf
update
liquibase peut être lancé également via maven, java, spring, ant, grails, servlet
listener

16.
Gestion du changement avec Liquibase
includes
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.9"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.9
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">
<include file="com/example/news/news.changelog.xml"/>
<include file="com/example/directory/directory.changelog.xml"/>
<includeAll path="com/example/changelogs/"/>
</databaseChangeLog>

17.
Gestion du changement avec Liquibase
contexts
<changeSet id="2" author="bob" context="test">
<insert tableName="news">
<column name="id" value="1"/>
<column name="title" value="Liquibase 0.8 Released"/>
</insert>
<insert tableName="news">
<column name="id" value="2"/>
<column name="title" value="Liquibase 0.9 Released"/>
</insert>
</changeSet>

18.
Gestion du changement avec Liquibase
sql statements
<changeSet author='jsmith' id='1'>
<sql>
ALTER TABLE clients ADD COLUMN nbOrders int(11);
</sql>
</changeSet>

19.
Gestion du changement avec Liquibase
rollbacks
<changeSet id="changeRollback" author="nvoxland">
<createTable tableName="changeRollback1">
<column name="id" type="int"/>
</createTable>
<rollback>
<dropTable tableName="changeRollback1"/>
</rollback>
</changeSet>

20.
Gestion du changement avec Liquibase
commandes: update/rollback

21.
Gestion du changement avec Liquibase
commandes: diff/doc/maintenance

22.
Gestion du changement avec Liquibase
diff
liqubase.sh --driver=oracle.jdbc.OracleDriver
--url=jdbc:oracle:thin:@testdb:1521:test
--username=bob
--password=bob
diff
--referenceUrl=jdbc:oracle:thin:@localhost/XE
--referenceUsername=bob
--referencePassword=bob

23.
Gestion du changement avec Liquibase
diff

24.
Liquibase chez Viadeo

25.
Liquibase chez Viadeo
organisation
● Un module maven viadeo-core-database centralise tous les changesets
● Les changesets sont organisés en changelogs, orientés projets
● Les changelogs sont organisés par clusters et par tables
● Trois types de répartition des changelogs au sein d'un cluster : struct, ref, test
au sein desquels les changelogs sont triés par leur nom de fichier
● Trois contextes disponibles : pre-rollout, post-rollout, devonly
viadeo-core-database/src/main/resources/db
○ cluster1
■ table1
● struct
○ Changelog-20120922-myproject.sql
○ Changelog-20121024-yourproject-.sql
● ref
● test
■ table2
○ cluster2
○ ...

26.
Liquibase chez Viadeo
execution
Afin de ne pas avoir à gérer les inclusions de changelogs et offir une plus grande
souplesse d'exécution, un mojo maven s'occupe de générer les changesets
intermédiaires.
● Les développeurs n'ont à se soucier que de la création/maintenance des
changelogs de leur projet et les répartir correctement
● Liquibase peut alors être appelé via maven qui va se charger à l'aide du mojo
dédié de créer le changelog racine en fonction des paramètres soumis (struct, ref,
test, cluster)
● Un script shell wrapper fourni une exécution plus aisée et directe sur les serveurs
ou postes de développement GNU/Linux.
● Des launchers eclipse facilitent le lancement depuis l'IDE

27.
Liquibase chez Viadeo
mojo maven
<!-- LIQUIBASE INTERMEDIATE CHANGELOGS GENERATION -->
<plugin>
<groupId>com.viadeo</groupId>
<artifactId>viadeo-core-database-gen</artifactId>
<version>1.0.1</version> viadeo-core-database/target/classes/db
<executions> ○ cluster1
<execution>
■ table1
● struct
<goals>
● ref
<goal>generate</goal> ● test
</goals> ■ table2
</execution>
■ Changelog.xml
○ cluster2
</executions>
○ ...
</plugin>

28.
Liquibase chez Viadeo
maven
<!-- LIQUIBASE BASE CONFIGURATION -->
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>2.0.5</version>
<configuration>
<propertyFileWillOverride>true</propertyFileWillOverride>
<propertyFile>${project.build.outputDirectory}/db/${liquibase.db}/${liquibase.props}
</propertyFile>
<changeLogFile>${project.build.outputDirectory}/db/${liquibase.db}/Changelog.xml</changeLogFile>
<driver>com.mysql.jdbc.Driver</driver>
<promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
</configuration>
</plugin>

29.
Liquibase chez Viadeo
maven full build avec ant
<target name="do.update.all" depends="init"> <target name="do.update.test.all" depends="init">
<property name="test" value=false"" /> <property name="test" value="true" />
<maven goals="clean process-resources" profiles=" <maven goals="clean process-resources" profiles="
viadeo.dynamic" /> viadeo.dynamic" />
<antcall target="do.update.cluster1" /> <antcall target="do.update.cluster1" />
<antcall target="do.update.cluster2" /> <antcall target="do.update.cluster2" />
... ...
</target> </target>

30.
Liquibase chez Viadeo
shell wrapper

31.
Liquibase chez Viadeo
mise en production
Jusqu'à la préproduction l'application des changesets est faite automatiquement.
Le filtrage des requêtes pour la production est faite post-preprod pour une application
manuelle (extraction des scripts SQL afin d'assurer l'ordre et l'heure d'application).
Actuellement en cours de test et d'industrialisation.

32.
Liquibase chez Viadeo
points d'attention / bonnes pratiques
● Les ids des changesets doivent être contrôlés afin d'assurer leur unicité (séquence ou
nommage standardisé)
● Toujours spécifier la propriété author des changesets, cela simplifiera la lecture et
l'exploitation de l'historique, de plus cette propriété est utilisée par liquibase afin de
renforcer l'unicité de l'id.
● NE JAMAIS MODIFIER UN CHANGESET UNE FOIS LE COMMIT EFFECTUE SUR
LE SCM
○ En effet liquibase génère une signature numérique du contenu de chaque changeset qu'il
stocke dans sa base de suivi. Une modification de cette signature n'est donc pas gérable
pour lui, et constitue une violation de la logique de suivi de version.
● Utiliser les contextes, il peuvent s'avérer être une aide précieuse
La séquence d'ajout de changeset conseillée est la suivante :
1. Créer le changeset (ajout ou édition d'un changelog existant)
2. Executer liquibase sur la base de développement afin de le tester
3. Effectuer les modifications du code
4. Tester le code de l'application
5. Pousser le code et le nouveau changeset sur le SCM

33.
Merci de votre attention,
à vos questions!