Martin Fowler a écrit mon article préféré sur le sujet, http://martinfowler.com/articles/evodb.html. Je choisis de ne pas mettre les vidages de schéma sous contrôle de version en tant que alumb et d'autres suggèrent parce que je veux un moyen simple de mettre à jour ma base de données de production.
Pour une application Web où j'aurai une seule instance de base de données de production, j'utilise deux techniques :
Scripts de mise à niveau de la base de données
Une séquence de scripts de mise à niveau de la base de données contenant le DDL nécessaire pour déplacer le schéma de la version N vers N+1. (Ceux-ci vont dans votre système de contrôle de version.) Une table _version_history_, quelque chose comme
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
obtient une nouvelle entrée à chaque exécution d'un script de mise à niveau correspondant à la nouvelle version.
Cela garantit qu'il est facile de voir quelle version du schéma de base de données existe et que les scripts de mise à niveau de la base de données ne sont exécutés qu'une seule fois. Encore une fois, ce ne sont pas vidages de la base de données. Au contraire, chaque script représente les changements nécessaires pour passer d'une version à l'autre. Il s'agit du script que vous appliquez à votre base de données de production pour la "mettre à niveau".
Synchronisation Sandbox développeur
- Un script pour sauvegarder, nettoyer et réduire une base de données de production. Exécutez ceci après chaque mise à niveau vers la base de données de production.
- Un script pour restaurer (et modifier, si nécessaire) la sauvegarde sur le poste de travail d'un développeur. Chaque développeur exécute ce script après chaque mise à niveau vers la base de données de production.
Une mise en garde :Mes tests automatisés s'exécutent sur une base de données au schéma correct mais vide, donc ce conseil ne répondra pas parfaitement à vos besoins.
