image

Comment fonctionne le versionning de base de données ?

J’ai récemment décrit comment mettre en place de l’intégration continue afin d’intégrer automatiquement les modifications de schéma de bases de données sur des bases de données de test par exemple.

On m’a à cette occasion très justement indiqué que j’aurais pu décrire comment fonctionne le versionning de base de données.

Je vais donc décrire via ce post comment gérer dans un SCM une base de données, et je vais l’illustrer via l’utilisation de RedGate SQL Source Control. Les principes fondamentaux restent identiques pour les autres outils de la catégorie.

Cet outil peut être utilisé avec différents SCM : SVN, Git, Mercurial et bien évidemment avec TFS.

Une fois installé, vous disposez d’un nouvel onglet dans SQL Server Management Studio, celui-ci vous permet d’effectuer les principales tâches de gestion de version d’une base de données :

  • Définition du lien avec le SCM de votre choix
  • Opérations Get Latest et Commit

Première étape à réaliser donc, établir le lien entre une base de données et votre SCM :

image

A noter que ce lien étant stocké sur la machine où il est réalisé, il doit être réalisé sur chaque poste de développement.

Une fois le lien effectué, RedGate SQL Source Control va scruter en continu les modifications effectuées sur votre base de données. Il sera ainsi capable de vous indiquer les modifications effectuées lorsque vous souhaiterez faire un commit.

Le développeur peut donc effectuer les modifications qu’il souhaite sur sa base et va ensuite être capable de faire un commit dans le source control de ses modifications.

A noter qu’afin d’être capable de stocker les informations de schémas d’une base de données dans n’importe quel SCM il faut être capable de créer un ou plusieurs fichiers représentant ce schéma.

La plupart des outils de versionning de bases de données fonctionne de la même manière.

Un des objectifs de la mise en place de versionning étant la capacité de recréer from scratch une BDD propre, les outils crééent un script de création de chaque “objet” (Table, Vue, Procédure stockée, Trigger, etc.) et stockent ces fichiers dans le repository.

Ainsi le premier commit effectué depuis RedGate génère la structure suivante dans le source control :

image

Un petit tour dans le dossier de définition des tables et nous retrouvons notre table de test stockée sous forme de fichier .sql :

image

Ce fichier SQL contenant le script de création de la table avec l’ajout du champ et de la clé primaire :

image

A chaque modification de schéma, l’outil de versionning de BDD va ainsi générer le même script de création mis à jour en fonction des modifications de schéma effectuées. Ainsi un ajout de champ “nom_test” génère une nouvelle version du fichier Test.sql :

image

 

Vous retrouverez également ces scripts directement dans SQL Source Control lorsque vous effectuerez un GetLatest :

image

Bien évidemment, lorsque l’on effectue ce GetLatest, RedGate SQL Source Control ne vas pas bêtement remplacer la table en exécutant directement le script de création présent dans le source control mais il va générer un script de modification adéquat  afin de préserver les données présentes :

image

Cette génération de requête à partir du diff de deux requêtes de création est d’ailleurs la seule partie complexe de ce type de logiciels.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *