Comparación y selección de sistemas de migración de datos.
El modelo de datos tiende a cambiar durante el proceso de desarrollo y, en algún momento, ya no se corresponde con la base de datos. Por supuesto, la base de datos se puede eliminar y luego el ORM creará una nueva versión que coincidirá con el modelo, pero este procedimiento provocará la pérdida de los datos existentes. Así, la función del sistema de migración es asegurar que, como resultado de un cambio de esquema, se sincronice con el modelo de datos en la aplicación sin perder datos existentes.
En este artículo, nos gustaría analizar varias herramientas para gestionar las migraciones de bases de datos. Esperamos que esta revisión sea útil para los desarrolladores que se enfrentan a una elección similar.
Tarea
Actualmente, nuestra empresa está desarrollando activamente la próxima generación de productos: Docs Security Suite (DSS). La parte del servidor está escrita en .Net Core y Entity Framework Core se utiliza como DBMS. Al diseñar una aplicación, utilizamos el enfoque Code First.
El modelo de dominio de la aplicación lo crean varios desarrolladores al mismo tiempo; cada uno es responsable de su propia parte lógica del sistema.
La generación anterior de DSS utilizaba el clásico Entity Framework Migrations (EF 6) como sistema de gestión de migraciones. Sin embargo, se han acumulado algunas quejas en su contra, la principal es que EF carece de un enfoque sensato para resolver conflictos de versiones. Este hecho todavía nos molesta a la hora de corregir errores como parte del soporte, por lo que decidimos considerar opciones alternativas.
Como resultado de la discusión, se formaron los siguientes requisitos para el sistema de gestión de migración:
- Soporte para varios DBMS. Se requieren MS SQL Server, PostgreSQL y Oracle, pero es posible utilizar otros.
- Trabajando con ORM. Inicialmente, se planeó usar EF Core, pero en la etapa de diseño estábamos listos para considerar otros ORM.
- Autogeneración de migraciones. Teniendo en cuenta el desarrollo de Code First, me gustaría evitar la necesidad de realizar migraciones “escrito a mano”.
- Conflictos de versión. En un entorno de desarrollo distribuido, al fusionarse, EF Core puede sufrir conflictos. Esto se convierte en un problema importante porque las diferentes partes de la aplicación son creadas por diferentes desarrolladores, por lo que hay que dedicar mucho tiempo a cada una.
- Documentación y soporte avanzados. Aquí, nos parece, no se necesita ninguna explicación.
- Gratis. El criterio es condicional, ya que los sistemas no son muy caros ni costosos, pero sí ideales en términos de conveniencia, también estábamos dispuestos a considerar
Como resultado de un poco de investigación, se encontraron las siguientes opciones, que resultaron deseables para su consideración:
- Migraciones principales de EF
- DBup
- RoundhouseE
- Pensando en casa.Migrator
- Migrador fluido
Y ahora un poco más de detalle.
Naturalmente, esta fue la primera y principal opción a elegir. Un instrumento nativo que funciona desde el primer momento sin tener que tocar una pandereta. Gran cantidad de documentación, oficial y no tan, sencillez, etc. Sin embargo, las quejas sobre EF clásico también son bastante relevantes para EF Core.
Así, se destacan las ventajas de EF Core:
- Soporte de Microsoft, documentación, incluso en ruso, gran comunidad.
- Autogeneración de migraciones basadas en CodeFirst
- En comparación con EF 6, EF Core ya no almacena una instantánea de la base de datos. Cuando se trabaja con EF Core en Code First, ya no es necesario implementar una base de datos
- Dado que estamos bailando desde Code First, es posible realizar una migración a todos los proveedores de acceso a datos requeridos.
- En cuanto a proveedores, se admite PostgreSQL, se admite Oracle, etc., etc., e incluso MS SQL Server
Y también las desventajas:
- La resolución de conflictos se mantuvo al mismo nivel. Es necesario secuenciar las migraciones y actualizar las instantáneas de la base de datos.
- Dependencia de los modelos sobre los que se generan las migraciones
DbUp
DbUp es una biblioteca .NET que instala NuGet y ayuda a enviar cambios a SQL Server. Realiza un seguimiento de qué scripts de cambios ya se han ejecutado y ejecuta los que son necesarios para actualizar la base de datos. La biblioteca surgió de un proyecto para un motor de blogs de código abierto en ASP.NET y existe bajo una licencia MIT, y el código está en GitHub. Las migraciones se describen utilizando T-SQL.
Cuáles son las ventajas:
- Soporte para una gran cantidad de DBMS (MS SQL Server, PstgreSQL, MySQL)
- Dado que los scripts están escritos en T-SQL, parecen bastante simples.
- Los conflictos también se resuelven usando SQL
Y los contras:
- Con toda la variedad de DBMS soportados, Oracle no es uno de ellos
- No interactúa con ORM
- Escribir scripts T-SQL a mano no es lo que buscábamos
- La documentación y la comunidad son regulares, aunque en términos de escritura de scripts SQL pueden no ser necesarios.
RoundhouseE
Esta herramienta de gestión de migraciones, distribuida bajo licencia Apache 2.0, al igual que la anterior, se ejecuta sobre el motor de migración T-SQL. Aparentemente, los desarrolladores dieron prioridad a resolver problemas técnicos relacionados con el soporte de DBMS, en lugar de crear un proceso de desarrollo cómodo.
Pros:
- Admite los DBMS necesarios (incluido Oracle)
Contras:
- Oracle (así como Access, que es irrelevante para nosotros) no es compatible con .NET Core, solo con .NET Full Framework
- No funciona con ORM
- Hay incluso menos documentación que la herramienta anterior.
- Nuevamente, las migraciones se escriben mediante scripts.
Pensando en casa.Migrator
Una herramienta para la migración de esquemas de bases de datos versionadas a la plataforma .NET Core, distribuida bajo licencia MIT. .
Pros:
- Diseñado para .NET Core
- Implementó una secuencia ramificada de migraciones.
- Registro de migración implementado
Contras:
- Última actualización hace un año. Al parecer el proyecto no es compatible.
- No es compatible con Oracle (el artículo indica que esto se debe a la falta de una implementación estable para .NET Core, pero de esto fue hace un año)
- Sin generación automática de migraciones.
En general, el proyecto parece prometedor, especialmente si se desarrollara, pero necesitábamos tomar una decisión aquí y ahora.
Migrador fluido
La herramienta de migración más popular y con un gran ejército de seguidores. Distribuido bajo la licencia Apache 2.0. Como se indica en la descripción, es un marco de migración para .NET, similar a las migraciones de Ruby on Rails. Los cambios en el esquema de la base de datos se describen en las clases de C#.
Aquí hay ventajas:
- Soporte para DBMS requerido
- Compatibilidad con .NET Core
- Gran comunidad desarrollada
- Los conflictos entre migraciones se resuelven secuencialmente: se especifica el orden de ejecución de las migraciones. Además, si surge un conflicto en torno a una entidad, al fusionar el código, se resuelve de la misma forma que en el resto del código.
- Hay perfiles que se ejecutan después de una migración exitosa. Y pueden llevar funciones de servicio. La última actualización fue hace un mes, es decir, el proyecto está vivo.
En cuanto a las desventajas, aquí están:
- Sin generación automática de migraciones.
- Sin conexión con los modelos EF
- Sin instantáneas de la base de datos
¿Cuál fue nuestra elección?
Los acalorados debates giraron en torno a dos parámetros: la generación automática de migraciones y la resolución sensata de los conflictos. Otros factores fueron mucho menos aterradores. Como resultado, basándose en los resultados de la discusión, el equipo decidió utilizar Fluent Migrator en el nuevo proyecto. Porque resolver conflictos en el futuro traerá muchos más beneficios.
Hallazgos
Por supuesto, no existen herramientas perfectas. Así que tuvimos que priorizar nuestros “deseos” para tomar una decisión. Sin embargo, para otros equipos y otras tareas, otros factores pueden ser decisivos. Esperamos que este artículo le ayude a tomar una decisión.
Fuente: habr.com