Подтвердить что ты не робот

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

Я могу использовать диспетчер пакетов для локального запуска "update-database -verbose".

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

Вторые - какие другие стратегии вы бы рекомендовали для развертывания миграции баз данных на производство - и как они были бы предпочтительнее?

Спасибо

4b9b3361

Ответ 1

У вас есть несколько вариантов:

  • Вы можете использовать update-database -script для генерации команд SQL для обновления базы данных на сервере.
  • Вы можете использовать исполняемый файл migrate.exe, который находится в папке пакета на /packages/EntityFramework5.0.0/tools/migrate.exe. Я использовал его в прошлом с Team Team Build Server для Jet Brains, чтобы настроить миграции с помощью моих сценариев развертывания.
  • Если вы используете IIS Web Deploy, вы можете сказать серверу выполнить миграцию после публикации (см. рис. ниже).
  • Вы можете настроить автоматическую миграцию, но я предпочитаю контролировать то, что происходит:)

Обновление: Также, зайдите в Sayed Ibrahim blog, он работает в команде MsBuild в Microsoft и имеет некоторые важные сведения о развертываниях

enter image description here

Ответ 2

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

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

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

Ответ 3

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

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

НТН.

Ответ 4

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

Отправляй сообщение из AppHarbor. http://blog.appharbor.com/2012/04/24/automatic-migrations-with-entity-framework-4-3

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

чтобы дать каждому простой ответ.

Это "Обновление-База данных", В папке Migrations Configuration.cs:

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

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

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