Migrator.net vs fluentmigrator vs migsharp

В настоящее время я изучаю возможные варианты структуры/инструмента миграции. Мне нравится идея рубиновых миграций, на которых основаны эти рамки.

Итак, я прошу вашего опыта, мнений и, может быть, сравнения между ними. Вы используете их в производстве?

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

В любом случае, я решил пойти с MigSharp, так как кодовая база кажется довольно чистой, и ее довольно легко обрабатывать и она поддерживает поддержку MS SQL CE. Второе занятие было бы FluentMigrator, где я не смог создать рабочий пример для компактной версии.

Приветствия

Ответы

Ответ 1

Я использую FluentMigrator в производстве и являюсь давним участником FM. Я думаю, что ваш вопрос - общий; Более конкретно. Кроме того, у FM есть группа google, которая довольно активна, если вам нужна информация FM.

FM, как я помню, получен из migrator.net. Он использует свободный синтаксис и поддерживает несколько баз данных. Мы немного вдохновлялись миграциями рельсов, но это определенно не порт. Стоит проверить.

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

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

Ответ 2

Я использую mig #.

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

Мы используем порядковый номер в конце наших миграций, а не штамп даты. Это связано с тем, что мы не знаем, когда была установлена ​​отметка времени даты (когда они начали набор изменений исходного кода, как раз перед фиксацией, некоторое время между ними) разные разработчики могли использовать разные подходы.

Имена, такие как Migration_0000034.cs, дают вам много места.

Ответ 3

В этот момент я буду придерживаться migrator.net. Мне нравится обещание FluentMigrator, но у него, похоже, нет более активной активной разработки, чем migrator.net(см. Проблемы и запросы на загрузку, которые томились на своем сайте github).

Также нет простого способа выполнить ExecuteScalar(). Я бы добавил его, но я не хочу создавать свою собственную вилку, и я не вижу причин, чтобы запрос на тягу фактически попадал в мастера. (Execute.WithConnection - это действие, поэтому оно срабатывает по требованию, а не тогда, когда мне нужно его запустить)

Итак, для меня, я возвращаюсь к migrator.net.