Embed Size (px)
DESCRIPTION
Pourquoi mettre en place une gestion de version sur sa base de données ? La solution liquibase Viadeo http://fr.viadeo.com/fr/profile/loic.diasdasilva
Citation preview
Viadeo Tech Days
Gestion du changement et bases de données, avec Liquibase
Programme
1. Gestion du changement et bases de données
2. Liquibase
3. Liquibase chez Viadeo
Gestion du changement et Bases de données
Gestion du changement et Bases de donnéespourquoi ?
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.
Gestion du changement et Bases de donnéesles 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
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
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é
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
Gestion du changement et Bases de donnéesconclusion
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.
Gestion du changement et Bases de donnéespour 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. "
Gestion du changement avec Liquibase
Gestion du changement avec Liquibase
source: http://www.liquibase.org/
Gestion du changement avec Liquibasefeatures
● 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
Gestion du changement avec LiquibaseChangelogs/Changesets
source: http://www.liquibase.org/
Gestion du changement avec Liquibasemigration 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
Gestion du changement avec Liquibaseincludes
<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>
Gestion du changement avec Liquibasecontexts
<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>
Gestion du changement avec Liquibasesql statements
<changeSet author='jsmith' id='1'> <sql>
ALTER TABLE clients ADD COLUMN nbOrders int(11); </sql> </changeSet>
Gestion du changement avec Liquibaserollbacks
<changeSet id="changeRollback" author="nvoxland"> <createTable tableName="changeRollback1"> <column name="id" type="int"/> </createTable> <rollback> <dropTable tableName="changeRollback1"/> </rollback> </changeSet>
Gestion du changement avec Liquibasecommandes: update/rollback
Gestion du changement avec Liquibasecommandes: diff/doc/maintenance
Gestion du changement avec Liquibasediff
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
Gestion du changement avec Liquibasediff
Liquibase chez Viadeo
Liquibase chez Viadeoorganisation
● 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○ ...
Liquibase chez Viadeoexecution
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
Liquibase chez Viadeomojo maven
<!-- LIQUIBASE INTERMEDIATE CHANGELOGS GENERATION -->
<plugin>
<groupId>com.viadeo</groupId>
<artifactId>viadeo-core-database-gen</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
viadeo-core-database/target/classes/db○ cluster1
■ table1● struct● ref● test
■ table2■ Changelog.xml
○ cluster2○ ...
Liquibase chez Viadeomaven
<!-- 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>
Liquibase chez Viadeomaven full build avec ant
<target name="do.update.all" depends="init">
<property name="test" value=false"" />
<maven goals="clean process-resources" profiles="viadeo.dynamic" />
<antcall target="do.update.cluster1" />
<antcall target="do.update.cluster2" />
...
</target>
<target name="do.update.test.all" depends="init">
<property name="test" value="true" />
<maven goals="clean process-resources" profiles="viadeo.dynamic" />
<antcall target="do.update.cluster1" />
<antcall target="do.update.cluster2" />
...
</target>
Liquibase chez Viadeoshell wrapper
Liquibase chez Viadeomise 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.
Liquibase chez Viadeopoints 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 tester3. Effectuer les modifications du code4. Tester le code de l'application5. Pousser le code et le nouveau changeset sur le SCM
Merci de votre attention,
à vos questions!
Adrien DEBBAHResponsables des Partenariats France
http://www.viadeo.com/fr/profile/adrien.debbah
