EF Migrations - comment gérer pendant le développement et le déploiement?

Question

Nous envisageons d'utiliser des migrations basées sur le code EF 4.3.1, mais nous ne savons pas comment intégrer les migrations avec notre méthodologie de développement/déploiement actuelle ...

L'application en question est une application WPF de bureau , chaque bureau ayant sa propre instance SQL Server (chacune avec 4 bases de données distinctes). Il est déployé dans un environnement «de terrain» sans support informatique local. Toute migration de base de données doit être effectuée à l'aide de scripts SQL exécutés par le programme d'installation (probablement InstallShield). Il n'y aura personne disponible qui peut exécuter une commande à une invite PMC pour mettre à niveau la base de données lorsqu'elle est déployée/mise à niveau à un emplacement sur le terrain. Ainsi, la «sortie» finale de EF Migrations doit être un ensemble de scripts SQL, que l'installateur va appliquer de manière sélective.

De plus, nous avons plusieurs développeurs qui effectuent des changements de base de données simultanés. Il n'y a pas de DBA. Chaque développeur vérifie simplement les modifications de code (modèle) apportées à TFS, et la prochaine fois qu'il obtient get-latest, les modifications apportées au modèle provoquent automatiquement la création d'une nouvelle base de données sur son système de développement. Alors, comment pouvons-nous faire en sorte que chaque développeur effectue ses propres migrations locales (plutôt que de supprimer/recréer ses bases de données locales), puis de gérer/consolider/combiner ces migrations? Et qu'en est-il des collisions? Pendant les tests de développement et les tests unitaires, chaque développeur peut supprimer sa base de données locale (entière) plusieurs fois au cours d'une seule vérification de caisse/vérification. Cela fonctionne très bien avec Code First, car la base de données est automatiquement reconstruite lorsque l'application est redémarrée. Mais cela signifie que la table _MigrationHistory de la base de données est également supprimée. Comment allons-nous gérer ceci? N'avons-nous pas besoin de l'historique de la migration de chaque système de développement? Si non, où/comment détectons-nous les changements globaux qui doivent être appliqués au système fourni? Je vois l'utilité d'utiliser Migrations pour gérer les mécanismes de migration d'une base de données, mais ce qui n'est pas clair, c'est comment en tirer parti sans introduire un goulot d'étranglement centralisé dans le cycle de développement. perdant ainsi l'un des avantages clés de Code First.

Tout aperçu/conseil serait grandement apprécié!

DadCat

Answer 1

Je sais c'est une vieille question, mais je pensais que je posterai certaines de mes expériences avec EF (v6.1) Migrations.

Chaque dev ira bien. Les migrations sont placées dans des classes avec un horodatage dans le nom, donc aucune collision ne se produira. La base de données sur la machine du développeur sera mise à jour après avoir effectué une dernière tentative et exécuté l'application (ou la commande update-database).

La suppression de la base de données locale et la recréation s'effectuent correctement. Assurez-vous simplement que le dev exécute update-database avant d'ajouter des migrations supplémentaires ou que les choses ne seront plus synchronisées. Je suis un peu confus quant à pourquoi ils auraient besoin de supprimer la base de données locale, mais c'est hors de portée. Vous pouvez constater que votre processus doit être modifié pour prendre en charge les migrations EF.

Je ne peux pas vous aider avec la question de l'installateur, comme une question similaire m'a amené ici. La commande update-database dispose d'une option -script qui va générer le script de changement correct, mais je ne sais pas comment l'automatiser sur un serveur de build.