Как вы реплицируете изменения макета базы данных на производственном сервере?

Question

Предположим, я хочу добавить новую функцию в мое приложение ASP.NET MVC, работающее на SQL Server 2008 в качестве источника данных. Чтобы реализовать эту новую функцию, мне нужно добавить несколько новых столбцов в существующие таблицы базы данных.

После внесения этих изменений на моем сервере разработки и реализации новых функций, какой самый простой способ выполнить те же изменения базы данных на рабочем сервере при развертывании новой версии моего приложения? Есть ли способ автоматизировать это?

Редактировать: Как я только что узнал, обозреватель серверов Visual Studio 2008, похоже, может извлечь необходимые изменения для меня, сравнив две разные схемы базы данных (щелкните правой кнопкой мыши базу данных, нажмите "Сравнить схему" «). Это обычно покрывает мои требования или есть какие-то большие ошибки при использовании этой функции?

Answer 1

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

Answer 2

Red Gate SQL Compare может сделать это за вас, если ваши потребности относительно просты. В противном случае такой инструмент, как ER-Win или ER-Studio, может обрабатывать сложные схемы и миграции.

Answer 3

У вас должно быть управление версиями уровня базы данных и приложения. Период. Если у вас есть версия db 1.0 и уровень приложения 1.0, все изменения, которые будут выполнены позже для версий 1.1 и 1.1.5, должны быть «обновляемыми» с помощью сценариев. Все операторы "alter table" и "alter proc" выполняются с помощью сценариев.

Или альтернативно: Восстановите 1.0 db в базу данных db_old. Создайте производственную базу данных из сценариев и просто скопируйте данные (если у вас нет очень сложной базы данных, это не должно быть сложно) Автоматическое развертывание для applayer 1: 0.

Еще раз для всего процесса вы должны обучить его в DEV, протестировать в TEST, проверить его в qa и в последнее время выполнить в среде PROD.

Редактировать: лично я думаю, что если команда не может плавно перейти с версии 1.0 на 1.1 одновременно на DEV - пахнет плохим дизайном и смешивает обязанности относительно того, что должно быть на уровне приложения и что на сервер БД