Рабочий процесс nhibernate + migrations
Я хочу уточнить свой рабочий процесс вокруг NHibernate и относительно часто меняющуюся схему, и как лучше всего справиться с этим - я хотел бы, чтобы одно и то же решение применимо к производственным системам, поэтому я думаю, что мне нужен механизм миграции, а не просто обновление схемы.
Что я хочу знать, так это то, как я могу как можно лучше доработать рабочий процесс, чтобы как можно меньше работать, чтобы синхронизировать мою базу данных с моей моделью домена. Подход сценариев к тарантино выглядит неплохо, но, похоже, не существует способа генерировать обновление script из моих сопоставлений nHibernate, поэтому я могу скомпоновать создание script или используя инструмент reddate sql compare, подобный инструменту, Есть ли что-то, что мне не хватает, что облегчит жизнь вокруг этапа генерации script?
Спасибо,
Крис
Ответы
Ответ 1
Я не использовал ни один из этих инструментов миграции для .net самостоятельно, но когда вы пытаетесь запустить Ruby on Rails в свое свободное время, лет назад я видел преимущества миграции по сравнению с сценариями t-sql, которые мы использовали на моей работе в то время.
Ответ 2
В недавнем проекте, который я видел, мы обнаружили, что миграции в сочетании с ветвлением VCS и NHibernate могут вызывать несколько головных болей и недостатков на этом пути.
Мы создали NHibernate для создания схемы с каждой автоматической сборкой (для среды разработки) наряду с некоторой загрузкой данных.
В производственной среде у нас был script, основанный на текущей схеме и желаемой схеме, он сгенерировал одну миграцию с необходимыми полями и изменениями.
Ответ 3
Мы используем SQL Compare. Он оплачивается, но стоит инвестиции imho. Храните каждый из сгенерированных скриптов хорошо организованным - то есть timestamped - и вы получите хороший способ генерации базы данных для любой из выпущенных версий.
Это наш обычный поток
- Во время DEV у нас есть две базы данных "ProjectName" и "ProjectName_TEST" .
- Для каждого изменения схемы мы генерируем (NHibernate) новую базу данных и заменяем "ProjectName_TEST" .
- Мы используем SQL Compare для обновления "ProjectName" (поэтому сохраняем в нем все данные dev).
- В релизе мы сравниваем "ProjectName_TEST" с производственной базой данных и генерируем обновление script.
Посмотрите параметры командной строки, поскольку они весьма удобны для автоматизации процесса с помощью событий сборки VS.