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.