web-dev-qa-db-fra.com

ASP.NET MVC 4, Migrations - Comment exécuter 'update-database' sur un serveur de production

Je peux utiliser le gestionnaire de paquets pour exécuter localement «update-database -verbose».

Probablement une question stupide mais je ne le trouve pas en ligne - une fois mon site Web déployé - comment puis-je l'exécuter manuellement sur le serveur?

Deuxièmement - quelles autres stratégies recommanderiez-vous pour déployer les migrations de bases de données en production - et comment seraient-elles préférables?

Merci

asp.net-mvcentity-frameworkasp.net-mvc-4entity-framework-5code-first-migrations
23
niico

Vous avez plusieurs options:

  • Vous pouvez utiliser update-database -script pour générer les commandes SQL permettant de mettre à jour la base de données sur le serveur.
  • Vous pouvez utiliser le fichier migrate.exe executable qui réside dans le dossier du package sur /packages/EntityFramework5.0.0/tools/migrate.exe. Je l'ai utilisé avec succès par le passé avec Team City Build Server de Jet Brains pour configurer les migrations avec mes scripts de déploiement.
  • Si vous utilisez IIS Web Deploy, vous pouvez indiquer au serveur d'effectuer les migrations après la publication (voir l'image ci-dessous).
  • Vous pouvez configurer des migrations automatiques, mais je préfère avoir le contrôle du moment où les choses se passent :)

Mise à jour: Consultez également le blog de Sayed Ibrahim , il travaille pour l'équipe MsBuild de Microsoft et a de très bonnes idées sur les déploiements. 

enter image description here

27
amhed

Je sais que la question est déjà résolue, mais pour référence future:

Une des options est de mettre quelque chose comme ceci dans le constructeur de votre classe de contexte de base de données:

public MyDbContext()
    {
        System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, Configuration>());            
    }
9
Martin Falc

Pour nous, les administrateurs de base de données sont le seul groupe à avoir accès aux environnements de production (et de pré-production). Nous utilisons simplement la commande de console Update-Database -Script package pour obtenir le SQL requis pour mettre à jour la base de données. Ceci leur est remis où ils peuvent le valider, etc.

Peut-être un peu trop simpliste pour certains mais cela fonctionne.

HTH.

4
Sean Kenny

Une solution simple: exécuter Update-Database à partir de votre console Package Manager Console locale en fournissant un paramètre de chaîne de connexion avec la chaîne de connexion de production. Vous devez également fournir le nom du fournisseur de connexion (SqlServer dans cet exemple de code):

Update-Database -ConnectionString <your real remote server connection string here> -ConnectionProviderName System.Data.SqlClient

Au lieu de la chaîne de connexion, vous pouvez utiliser un nom de chaîne de connexion présent dans votre section connectionStrings du fichier app.config:

Update-Database -ConnectionStringName <your connection string name here>

Vous devez avoir des autorisations pour accéder à ce serveur à partir de votre ordinateur local. Par exemple, si vous parvenez à vous connecter au serveur à partir d'un SQL Server Management Studio, vous pouvez l'utiliser.

Notez que cette approche n'est pas recommandée pour un système de production réel. Vous devez utiliser quelque chose comme ce qui est expliqué dans la réponse acceptée. Mais cela peut vous aider avec des hacks rapides dans les serveurs de développement distants, les environnements de test, etc.

2
Diana

Personnellement, j'aime bien configurer des migrations automatiques qui s'exécutent chaque fois que la méthode de démarrage de l'application est appelée. Ainsi, à chaque déploiement, les migrations sont exécutées et mises à jour automatiquement.

Découvrez ce post de AppHarbor. http://blog.appharbor.com/2012/04/24/automatic-migrations-with-entity-framework-4-3

Le Gist indique en gros que vous souhaitez activer les migrations automatiques, puis appelez DatabaseInitializer à partir de votre code, à partir de la méthode OnModelCreating ou de votre fichier Global.asax.

1
Khalid Abuhakmeh

juste pour donner à chacun la réponse simple.

C'est la "base de données de mises à jour" Dans votre dossier Migrations, Configuration.cs:

    internal sealed class Configuration : DbMigrationsConfiguration<projectname.Models.dbContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = true;
        AutomaticMigrationDataLossAllowed = true; // Update-Data -Force (deletes columns etc)
    }

Et pour "Activer les migrations" en premier lieu sur un serveur distant, ajoutez ceci à votre fichier Global.asax.cs:

        protected void Application_Start()
    {
        ....
        System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<dbContext, Migrations.Configuration>());
0
Worthy7

Vous pouvez obtenir les scripts à l'aide des commandes EF (update-database -script) ou vous pouvez l'écrire manuellement. Ce n'est pas la chose la plus importante à propos de la mise à jour de la base de données dans un environnement de production. Pour moi, le plus important est de s’assurer que tous les scripts ont été exécutés correctement et qu’ils ont affecté les enregistrements comme prévu. À mon avis, vous devriez avoir un environnement de préproduction et la base de données devrait être une copie de l’environnement de production. De cette façon, vous pouvez exécuter les scripts et déployer l'application dans un environnement assez similaire et voir s'il y a des problèmes. Parfois, les scripts sont exécutés correctement dans un environnement DEV mais échouent dans un environnement de production. Pour éviter les maux de tête, vous devez simuler l'environnement de production dans un environnement de préproduction . Concernant les scripts, si l'équipe a plusieurs développeurs, je préfère catégoriser les scripts dans des scripts de structure et des scripts de données. Les scripts de structure modifient la structure de la base de données (ajouter une table, ajouter une colonne à une table, etc.) et les scripts de données insèrent/mettent à jour/suppriment des enregistrements. En outre, chaque script doit spécifier ses dépendances afin qu'elles ne puissent pas être exécutées dans le mauvais ordre. Un script de données qui insère des lignes dans la table A ne peut pas être exécuté tant que la table A n'a pas été créée. C’est ce que je fais: - Définir une table pour l’enregistrement des scripts exécutés. Par exemple: ExecutedScriptsHistory .- Chaque script a un numéro et un nom .- Après l'exécution d'un script, une nouvelle ligne est insérée dans la table ExecutedScriptsHistory .- Avant son exécution, il vérifie sa dépendances. Pour ce faire, il vérifie si les scripts ont été exécutés (existe dans la table ExecutedScriptsHistory).

Après avoir exécuté les scripts, vous pouvez vérifier si tous les scripts ont été exécutés en vérifiant ExecutedScriptsHistory. Cette stratégie est similaire à celle choisie par Microsoft dans EF Migration, mais vous en avez le contrôle total.

0
Francisco Goldenstein