migrator.net vs fluentmigrator vs migsharp

Question

Actualmente estoy investigando las posibles opciones de un marco/herramienta de migración. Me gusta la idea de las migraciones de ruby ​​en las que se basan los marcos anteriores.

Así que les pido su experiencia, opiniones y tal vez una comparación entre ellos. ¿Los estás usando en producción?

---

gracias por las respuestas. El objetivo de esta pregunta era tener una idea de qué herramientas se usan más en la comunidad de desarrolladores, pero parece que las migraciones no son un tema candente aquí.

De todos modos, he decidido ir con MigSharp ya que la base de código parece ser bastante limpia y es bastante fácil de manejar y tiene soporte para MS SQL CE. El segundo finalista habría sido FluentMigrator, donde no pude producir un ejemplo funcional para la edición compacta.

Saludos

Answer 1

que utilizo FluentMigrator en la producción, y soy un colaborador de toda la vida a FM. Creo que tu pregunta es general; sé más específico. Además, FM tiene un grupo de google que está bastante activo si quieres información de FM.

FM se deriva de migrator.net, según recuerdo. Utiliza una sintaxis fluida y admite múltiples bases de datos. Nos hemos inspirado en las migraciones de rieles, pero definitivamente no es un puerto. Vale la pena echarle un vistazo.

Una cosa que he aprendido es no poner sus migraciones en el mismo ensamblaje que su código de aplicación. Sepárelos en un ensamblaje de migración y úselos para migrar sus bases de datos.

Además, siempre debe trabajar en múltiples entornos para evitar problemas con migraciones directas contra producción. Siempre tengo al menos un entorno de desarrollo y producción, y la mayoría de las veces también hay un entorno de prueba.

Answer 2

Yo uso mig #.

Funciona bien, pero deberá tener algunas pautas de uso, ya que las migraciones pueden ser complicadas.

Utilizamos el número de secuencia al final de nuestras migraciones en lugar de una marca de fecha y hora. Esto se debe a que no sabemos cuándo se estableció la marca de fecha y hora (cuando comenzaron el conjunto de cambios del código fuente, justo antes de comprometerse, algún tiempo entremedias) diferentes desarrolladores podían usar diferentes enfoques.

Nombres como Migration_0000034.cs le brindan mucho espacio.

Answer 3

En este punto, me quedaría con migrator.net. Me gusta la promesa de FluentMigrator, pero parece que no tiene un desarrollo activo mejor que migrator.net (consulte los problemas y las solicitudes de extracción languidecen en su sitio github).

Tampoco hay una manera fácil de hacer un ExecuteScalar(). Yo lo agregaría, pero no quiero crear mi propio tenedor, y no veo ninguna razón por la cual una solicitud de extracción realmente aterrice en el maestro. (Execute.WithConnection es una Acción por lo que se activará a demanda en lugar de cuando lo necesite para disparar)

Así que para mí, me dirijo a migrator.net.