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

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

une des options est de mettre quelque chose comme ça dans le constructeur de votre classe de contexte DB:

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

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

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

HTH.

personnellement, j'aime configurer des migrations automatiques qui s'exécutent chaque fois que la méthode de démarrage de l'application est appelée. De cette façon, avec chaque déploiement que vous faites, vous avez les migrations juste exécuter et mettre à jour l'application automatiquement.

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

l'essentiel est que vous voulez activer les migrations automatiques ensuite, appelez DatabaseInitializer à partir de votre code, soit à partir de la méthode OnModelCreating, soit à partir de votre Global.asax.

une solution simple: lancer Update-Database depuis votre Console locale de gestionnaire de paquets 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 une chaîne de connexion nom présent dans votre application.fichier de configuration connectionStrings section:

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

vous devez avoir des permissions pour accéder à ce serveur depuis votre machine locale. Par exemple, si vous êtes capable de vous connecter au serveur depuis un studio de gestion de Serveur Sql, vous pouvez utiliser ceci.

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

vous pouvez obtenir les scripts en utilisant des commandes EF (update-database-script) ou vous pouvez écrire le script manuellement. Ce n'est pas la chose la plus importante au sujet de la mise à jour de la base de données dans l'environnement de production. Pour moi, la chose la plus importante est de s'assurer que tous les scripts ont été exécutés correctement et 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 le 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 L'environnement DEV, mais ils échouent dans l'environnement de production. Pour éviter les maux de tête, vous devez simuler l'environnement de production dans un environnement de préproduction. En ce qui concerne les scripts, si l'équipe a plus d'un développeur, je préfère catégoriser les scripts dans les scripts de structure et les scripts de données. Les scripts de Structure modifient la structure de la base de données (ajouter un tableau, ajouter une colonne à une table, etc.) et des scripts de données inserts/updates / deletes records. De plus, 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 le tableau A ne peut pas être exécuté tant que le tableau a n'a pas été créé. C'est ce que je fais: - Définir une table pour enregistrer les 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 qu'un script ne soit exécuté, il vérifie ses dépendances. Pour ce faire, il vérifie si les scripts ont été exécutés (existe dans 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 la Migration EF, mais vous en avez le contrôle total.

juste pour donner à tout le monde la réponse simple.

C'est la "mise à jour-Base de données" 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 "Activer les migrations" en premier lieu sur un serveur distant, ajoutez ceci à votre Global.asax.fichier cs:

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