ASP.NET MVC 4, Migrations - Как запустить "update-database" на производственном сервере
Я могу использовать диспетчер пакетов для локального запуска "update-database -verbose".
Возможно, это глупый вопрос, но я не могу найти его в сети - как только мой сайт будет развернут - как я могу запустить его вручную на сервере?
Вторые - какие другие стратегии вы бы рекомендовали для развертывания миграции баз данных на производство - и как они были бы предпочтительнее?
Спасибо
Ответы
Ответ 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>());