ASP.NET MVC 4, миграции - как запустить "update-database" на производственном сервере

Я знаю, что на вопрос уже дан ответ, но для справки:

один из вариантов-поместить что-то подобное в конструктор вашего класса контекста DB:

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

для нас DBAs-единственная группа, имеющая доступ к производственным (и предпроизводственным) средам. Мы просто используем Update-Database -Script команда консоли пакета, чтобы получить Sql, необходимый для обновления базы данных. Это передается им, где они могут подтвердить это и т. д.

может быть, слишком упрощенно для некоторых, но это работает.

HTH.

Мне лично нравится настраивать автоматические миграции, которые запускаются каждый раз, когда вызывается метод запуска приложения. Таким образом, при каждом развертывании у вас есть миграции просто запустить и обновить приложение автоматически.

проверьте этот пост из AppHarbor. http://blog.appharbor.com/2012/04/24/automatic-migrations-with-entity-framework-4-3

суть в том, что вы хотите включить автоматическую миграцию, а затем вызвать DatabaseInitializer из вашего кода, либо от метод OnModelCreating или из глобального.асакс.

простое решение: работает Update-Database из локальной консоли диспетчера пакетов, предоставляющей параметр строки подключения с производственной строкой подключения. Вы также должны указать имя поставщика подключения (SqlServer в этом примере кода):

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

вместо строки подключения вы можете использовать имя строки подключения, присутствующее в вашем приложении.файл config :

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

у вас должны быть разрешения на доступ к этому серверу с вашего локального машина. Например, если вы можете подключиться к серверу из среды SQL Server Management Studio, вы можете использовать это.

обратите внимание, что этот подход не рекомендуется для реальной производственной системы, вы должны использовать что-то вроде того, что описано в принятой ответ. Но это может помочь вам с быстрыми взломами в разработке удаленных серверов, тестовых сред и т. д.

вы можете получить сценарии с помощью команд EF (update-database-script) или вы можете написать сценарий вручную. Это не самое главное в обновлении базы данных в производственной среде. Для меня самое главное-убедиться, что все скрипты были запущены правильно, и они повлияли на записи, как и ожидалось. На мой взгляд, у вас должна быть среда подготовки производства, а база данных должна быть копией производственной среды. Таким образом, вы можете запускать скрипты и разверните приложение в довольно похожей среде и посмотрите, есть ли какие-либо проблемы. Иногда сценарии выполняются правильно в среде разработки, но они терпят неудачу в рабочей среде. Чтобы избежать головной боли, следует имитировать производственную среду в среде подготовки производства. Что касается скриптов, если команда имеет более одного разработчика, я предпочитаю классифицировать скрипты в скриптах структуры и скриптах данных. Скрипты структуры изменяют структуру базы данных (добавить таблицу, добавить столбец к таблице и т. д.) и скрипты данных вставляет/обновляет / удаляет записи. Кроме того, каждый скрипт должен указывать свои зависимости, чтобы они не могли выполняться в неправильном порядке. Сценарий данных, вставляющий строки в таблицу A, не может быть выполнен до создания таблицы A. Вот что я делаю.: - Определите таблицу для регистрации выполненных скриптов. Например: ExecutedScriptsHistory. - Каждый сценарий имеет номер и имя. -После выполнения скрипта в таблицу вставляется новая строка ExecutedScriptsHistory. - Перед выполнением скрипта он проверяет его зависимости. Для этого он проверяет, были ли выполнены сценарии (существует в таблице ExecutedScriptsHistory).

после запуска скриптов Вы можете проверить, были ли выполнены все скрипты, проверяя ExecutedScriptsHistory. Эта стратегия аналогична стратегии, выбранной Microsoft в миграции EF, но вы полностью контролируете ее.

просто дать всем простой ответ.

Это "обновление базы данных" В папке миграции Configuration.cs:

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

и чтобы" включить миграции " в первую очередь на удаленном сервере, добавьте это в свой глобальный.асакс.cs файл:

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