Предположим что мы чиним багу и у нас что-то поменялось в базе данных: хранимки, таблицы, и т д. Допустим встает желание двинуть изменения на production, где уже есть база данных. Надо бы автоматизировать процесс деплоймента базы данных, хранить версии итп.
Каким образом вы реализуете инкрементальный деплой базы данных?
Надо иметь систему версий схемы базы и соответствующий набор миграционных патчей. При переходе на некую версию схемы нужно накатывать соответствующий набор патчей. Если очень сильно хочется автоматизации, то надо организовать эти патчи определённым образом, чтобы деплой скрипт всегда мог подцепить их и выполнить. Совсем уже детали зависят от специфики проекта и условий работы.
У нас есть внутренний продукт, который решает в том числе именно эту задачу.
Схема базы данных сохраняется в файл специального формата. При обновлении у заказчика с текущей версии его базы снимается такая же схема, потом она сравнивается со схемой, входящей в комплект поставки новой версии, и на основе результатов сравнения генерируется DDL-скрипт, обновляющий базу данных до соответствия новой схеме. Если в новую версию БД вносятся constraint'ы, вступающие в конфликт с существующими данными, то такие случаи отлавливаются на этапе тестирования, и к ним пишутся дополнительные скрипты, выполняемые перед автоматическим обновлением. Эти скрипты тоже включаются в комплект поставки продукта.
Некоторые ORM позволяют автоматически генерировать БД по объектной модели при первом обращении. Насколько я знаю, эта возможность есть у NHibernate, Subsonic и XPO. Работал только с XPO. Впечатления такие: наша система лучше.