Проектирование полного стека миграции базы данных

Question

Во время разработки мне нравится идея фреймворков, таких как Entity Framework 4.3 Migrations (хотя она нужна мне для работы со сценариями sql, а не с классами Migration), поддерживающей актуальность всех баз данных разработчиков. Кто-то делает обновление, чтобы получить последний источник, он пытается запустить приложение и выдает ошибку, что ему нужно обновить свою базу данных до последней миграции (или если миграция произойдет автоматически). Файлы миграции имеют временную метку, поэтому разработчикам не нужно беспокоиться о том, чтобы называть два файла одинаковыми, или о последовательности, в которой должны выполняться файлы.

Когда я собираюсь создать пакет развертывания WebDeploy, я хочу, чтобы пакет содержал сценарии, необходимые для перемещения производственной базы данных до последней версии БД. Так или иначе, MSBuild или WebDeploy должны принять решение о том, какие сценарии должны быть упакованы. Для развертывания я не хочу, чтобы приложение пыталось обновить себя так, как предлагает EF. Я хочу передать пакет ИТ-отделу или выполнить автоматическое развертывание через сервер развертывания.

Некоторые из моих вопросов:

1. Может ли EF 4.3 работать со сценариями sql вместо классов DBMigration для моих нужд разработки (я уже использую его для своего ORM, поэтому было бы неплохо, если бы это было возможно)?

2. Понимает ли MSBuild или WebDeploy концепцию миграции баз данных (например, распознает ли она таблицу EH. 4.3igrationHistory) или я должен предоставить ей только те сценарии, которые ему нужны для запуска, которые приведут мой продукт? дб до последней миграции? Решать, какие сценарии следует упаковать вручную, я не хочу, поэтому есть ли расширение MS WebDeploy, которое понимает миграции?

3. Обоснованы ли мои опасения и идеи? Я просто исследую этот материал, поэтому я не знаю.

Answer 1

Я думаю, что ваши опасения верны.Во время разработки будет работать все, что синхронизирует машины разработчика.При развертывании необходим больший контроль.

В моем проекте мы решили использовать только миграции на основе кода, чтобы все базы данных были перенесены в одинаковом порядке с одинаковыми шагами.Автоматическая миграция и создание базы данных отключены пользовательской стратегией инициализации, которая проверяет только то, существует ли база данных и является ли она действительной.

Более подробную информацию я написал в Запрет на миграцию EF при создании или изменении базы данных.Я также немного рассмотрел конфликтов слияния , которые в конечном итоге произойдут с несколькими разработчиками.

Answer 2

1. Вы можете запустить SQL в классах, вызвав метод Sql, или сгенерировать SQL из миграции, используя параметр -script с командой update-database.

2. Нет. Они надеялись добавить поддержку webdeploy, но, видимо, решили не делать этого до rtm. Однако они выпустили приложение для командной строки (и, очевидно, скрипт powershell), которое можно вызвать из любого из них.

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