Concevoir une pile de migration complète de la base de données

Question

Pendant le développement, j'aime l'idée de frameworks comme Entity Framework 4.3 Migrations (bien que j'en ai besoin de travailler avec des scripts SQL au lieu des classes de migration) en gardant toutes les bases de données de développeur à jour. Quelqu'un fait une mise à jour pour obtenir la dernière source, il essaie d'exécuter l'application et d'obtenir une erreur dont il a besoin pour mettre à jour sa base de données vers la dernière migration (ou que la migration se produise automatiquement). Les fichiers de migration sont horodgiens, les développeurs n'ont donc pas à se soucier de nommer deux fichiers de la même manière ou de la séquence dans laquelle les fichiers doivent être exécutés.

Lorsque je me prépare à créer un package de déploiement webdeploy, je veux que le package contienne les scripts requis pour déplacer la base de données de production vers la dernière version DB. Donc, en quelque sorte, MSBuild ou WebDeploy doit prendre une décision sur les scripts doit être emballé. Pour le déploiement, je ne veux pas que l'application essaie de se mettre à jour comme ce que l'EF offre. Je veux soit remettre le package au service informatique ou faire un déploiement automatique via un serveur de déploiement.

Certaines de mes questions sont:

1. EF 4.3 peut-il fonctionner avec des scripts SQL au lieu des cours de DBMIGRATION pour mes besoins de développement (je l'utilise déjà pour mon ORM, donc ce serait bien si cela le pouvait)?

2. MSBuild ou WebDeploy comprend-il le concept de migrations de base de données (par exemple, reconnaît-il le tableau Ef. 4.3 MigrationHistory) ou dois-je m'assurer de lui donner uniquement les scripts dont il a besoin pour exécuter qui apportera mon DB prod à la dernière migration? Décider manuellement quels scripts devraient être pakagés n'est pas quelque chose que je veux faire y a-t-il une extension MS WebDploy qui comprend les migrations?

3. Mes préoccupations et mes idées sont-elles valides? Je fais simplement des recherches sur ce genre de choses, donc je ne sais pas vraiment.

Answer 1

Je pense que vos préoccupations sont valables. Pendant le développement, tout ce qui maintient les machines des développeurs en synchronisation fera l'affaire. Lors du déploiement, plus de contrôle est nécessaire.

Dans mon projet, nous avons décidé d'utiliser uniquement des migrations basées sur le code, pour nous assurer que toutes les bases de données sont migrées dans le même ordre avec les mêmes étapes. La migration automatique et la création de DB sont désactivées par une stratégie d'initialisation personnalisée qui vérifie uniquement que la DB existe et est valide.

J'ai écrit plus sur les détails dans Empêcher les migrations EF de créer ou de modifier la base de données. J'ai aussi regardé un peu fusionner les conflits Ce qui finira par se produire avec plusieurs développeurs.

Answer 2

1. Vous pouvez exécuter SQL dans les classes en appelant la méthode SQL, ou générer SQL à partir d'une migration en utilisant le paramètre -Script avec la commande de mise à jour-database.

2. Non. Ils envisageaient d'ajouter du support pour WebDoldploy, mais apparemment décidé contre RTM. Ils ont cependant publié une application de ligne de commande (et un script PowerShell évidemment) que vous pourriez appeler l'un ou l'autre.

Ce que je fais dans mes projets, c'est de créer un module de démarrage dans mes applications et d'exécuter toutes les migrations qui n'ont pas été déployées automatiquement - Déclencher la migration EF au démarrage de l'application par code. Ce n'est pas parfait, les développeurs doivent exécuter l'application après avoir obtenu la plus récente avant de changer la base de données, mais cela fonctionne pour les deux pour obtenir le dernier et le déploiement.