Comment effectuez-vous la version / le suivi des modifications apportées aux tables SQL?

Lorsque vous travaillez dans une équipe de développeurs, où tout le monde modifie les tables locales et les tables de développement, comment synchronisez-vous toutes les modifications? Un fichier journal central où tout le monde conserve ses modifications SQL? Une page wiki pour suivre les instructions alter table, les fichiers .sql individuels que les développeurs peuvent exécuter pour apporter leurs bases de données locales à la dernière version? J'ai utilisé certaines de ces solutions, et je cherche à trouver une bonne solution solide qui fonctionne, alors j'apprécierais vos idées.

J'utilise un outil de migration de base de données basé sur le code et garde le code de migration sous contrôle de code source.

En utilisant des horodatages comme numéros de version, n'importe quel nombre de développeurs sont généralement libres d'ajouter des migrations à leur guise et nous pouvons exécuter l'outil de migration sur n'importe quelle copie de notre base de données en toute confiance.

J'avais l'habitude d'utiliser des scripts SQL sous contrôle de version, mais je trouve l'approche basée sur le code beaucoup, beaucoup plus facile à travailler car ils sont tous dans un "endroit" logique et capables d'exécuter tous les scripts nécessaires avec une seule commande.

Je ne le fais pas moi-même, mais certains développeurs maintiennent une collection de scripts SQL sous contrôle de source qui, une fois exécutés, peuvent recréer les tables de base de données à des fins de test et créer une base de données vide à des fins de production.

La même technique peut être utilisée pour versionner la base de données sur le site du client, lorsque des champs ou des tables doivent être ajoutés ou supprimés, ou que des transformations de données doivent avoir lieu.

Créez des scripts sous contrôle de version et intégration continue pour les vérifier

Une approche qui a fonctionné pour moi a été de faire travailler chaque développeur avec son propre schéma avec lequel il peut faire ce qu'il veut. Leur schéma était destructible et rempli de données de test provenant d'un ensemble de scripts contrôlés par la version auxquels tous les développeurs ont contribué.

Le build d'intégration continue nocturne a pris la dernière version de tous les scripts et a tenté de construire une base de données de test cohérente à partir d'eux. L'application a ensuite exécuté une série de tests d'intégration et de tests fonctionnels pour vérifier que le schéma actuel était conforme à la version actuelle candidate.

Avant de commencer dans cette voie, il y avait une conception de base de données assez solide en place et un DBA gardait toujours un œil sur les choses pour empêcher les développeurs de devenir fous de la dénormalisation et d'autres horreurs.

Le contrôle de version a énormément aidé ici car les modifications apportées aux scripts étaient immédiatement évidentes. Nous avons également utilisé une VERSIONtable de base de données pour identifier l'état général de la base de données. Il s'agissait d'une simple séquence entière et n'était liée à aucune application particulière.

Dans l'ensemble, cela a bien fonctionné et signifie que les développeurs ont cessé d'avoir peur de modifier les niveaux de persistance car ils pouvaient toujours annuler leurs propres schémas sans affecter les autres.

Si vous êtes dans une boutique MS, Visual Studio 2010 dispose de bons outils de contrôle de version de base de données, qui peuvent également générer des scripts de changement / déploiement en fonction des différences entre deux bases de données.

En plus de garder les schémas et autres scripts SQL sous contrôle de version, une autre pratique pratique consiste à maintenir une table de «version de schéma» dans la base de données réelle .

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

Doctrine dispose d'un formidable outil de migration: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations , la meilleure partie est qu'ils sont générés automatiquement ou peuvent être facilement codés à la main.

L'approche que j'utilise est de fournir une table pour les paramètres. Cette table aura une paire nom / valeur pour la version sur laquelle se trouve la base de données. Cela me donne deux avantages: j'ai un moyen de vérifier qu'un correctif de base de données a été appliqué via l'application, et je peux utiliser cette valeur pour mes scripts SQL.

Le script SQL créera de nouvelles tables, modifiera les colonnes et tout le travail nécessaire sur la base de données pour promouvoir le script à partir de la version précédente. Idéalement, j'aurais également un script de restauration, mais la plupart du temps je n'en ai pas.

BTW, toute cette approche a été automatisée dans le cadre de Ruby on Rails, avec les scripts de restauration. J'aime l'idée de cela, mais tous les cadres ne le font pas. Lorsque je n'utilise pas Ruby on Rails, j'utilise l'approche décrite ci-dessus.