C'est un peu low-tech, et il existe peut-être une meilleure solution, mais vous pouvez simplement stocker votre schéma dans un script SQL qui peut être exécuté pour créer la base de données. Je pense que vous pouvez exécuter une commande pour générer ce script, mais je ne connais malheureusement pas la commande.

Ensuite, validez le script dans le contrôle de code source avec le code qui fonctionne dessus. Lorsque vous devez modifier le schéma avec le code, le script peut être archivé avec le code qui nécessite le schéma modifié. Ensuite, les diffs sur le script indiqueront les diffs sur les changements de schéma.

Avec ce script, vous pouvez l'intégrer à DBUnit ou à une sorte de script de construction, il semble donc qu'il pourrait s'intégrer à vos processus déjà automatisés.

Si vous utilisez C

Mon équipe scripte toutes les modifications de la base de données et valide ces scripts sur SVN, ainsi que chaque version de l'application. Cela permet des modifications incrémentielles de la base de données, sans perdre de données.

Pour passer d'une version à l'autre, il vous suffit d'exécuter l'ensemble des scripts de modification, et votre base de données est à jour, et vous avez toujours toutes vos données. Ce n'est peut-être pas la méthode la plus simple, mais elle est certainement efficace.

Dumpez votre schéma dans un fichier et ajoutez-le au contrôle de code source. Ensuite, un simple diff vous montrera ce qui a changé.

Nous utilisons une solution très simple mais efficace.

Pour les nouvelles installations, nous avons un fichier metadata.sql dans le référentiel qui contient tout le schéma de base de données, puis dans le processus de construction, nous utilisons ce fichier pour générer la base de données.

Pour les mises à jour, nous ajoutons les mises à jour dans le logiciel codé en dur. Nous le gardons codé en dur parce que nous n'aimons pas résoudre les problèmes avant que ce ne soit vraiment un problème, et ce genre de chose ne s'est pas avéré être un problème jusqu'à présent.

Donc, dans notre logiciel, nous avons quelque chose comme ceci :

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Ce code va vérifier si la base de données est en version 1 (qui est stockée dans une table créée automatiquement), si elle est obsolète, alors la commande est exécutée.

Pour mettre à jour metadata.sql dans le référentiel, nous exécutons ces mises à niveau localement, puis extrayons les métadonnées complètes de la base de données.

La seule chose qui arrive de temps en temps, c'est d'oublier de commiter metadata.sql, mais ce n'est pas un problème majeur car c'est facile à tester sur le processus de construction et aussi la seule chose qui pourrait arriver est de faire un nouvelle installation avec une base de données obsolète et mise à jour lors de la première utilisation.

De plus, nous ne prenons pas en charge les rétrogradations, mais c'est par conception, si quelque chose se brise sur une mise à jour, nous avons restauré la version précédente et corrigé la mise à jour avant de réessayer.

J'ai utilisé la structure de projet de base de données suivante dans Visual Studio pour plusieurs projets et cela a plutôt bien fonctionné :

Base de données

Modifier les scripts

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Créer des scripts

Sprocs

Fonctions

Vues

Notre système de compilation met ensuite à jour la base de données d'une version à l'autre en exécutant les scripts dans l'ordre suivant :

1.PreDeploy.sql

2.SchemaChanges.sql

Contenu du dossier Créer des scripts

2.DataChanges.sql

3.Permissions.sql

Chaque développeur vérifie ses modifications pour un bogue/fonctionnalité particulier en ajoutant son code à la fin de chaque fichier. Une fois qu'une version majeure est terminée et ramifiée dans le contrôle de code source, le contenu des fichiers .sql du dossier Change Scripts est supprimé.