Comparación y selección de sistemas de migración de datos
El modelo de datos en el proceso de desarrollo tiene la propiedad de cambiar, y en algún momento deja de coincidir con la base de datos. Por supuesto, se puede eliminar la base de datos y, entonces, el ORM creará una nueva versión que corresponda al modelo, pero este procedimiento resultará en la pérdida de datos existentes. Por lo tanto, la función del sistema de migración consiste en sincronizar la estructura modificada con el modelo de datos en la aplicación sin pérdida de datos existentes.
En este artículo, nos gustaría revisar diversas herramientas para la gestión de migraciones de bases de datos. Esperamos que este resumen sea útil para los desarrolladores que se enfrenten a tal elección.
Tarea
En nuestra empresa, actualmente se está llevando a cabo el desarrollo activo de la próxima generación del producto: Docs Security Suite (DSS). La parte del servidor está escrita en .Net Core, y como SGBD se utiliza Entity Framework Core. Al diseñar la aplicación, estamos utilizando el enfoque Code First.
El modelo de dominio de la aplicación es creado simultáneamente por varios desarrolladores, cada uno de los cuales es responsable de su parte lógica del sistema.
En la generación anterior de DSS, se utilizó el clásico Entity Framework Migrations (EF 6) como sistema de gestión de migraciones. Sin embargo, se acumularon algunas quejas, la principal de las cuales era que EF carece de un enfoque razonable para resolver conflictos de versiones. Este hecho todavía nos molesta durante la corrección de errores en el marco del soporte, por lo que se tomó la decisión de considerar opciones alternativas.
Como resultado de la discusión, se formaron los siguientes requisitos para el sistema de gestión de migraciones:
- Soporte para diferentes SGBD. MS SQL Server, PostgreSQL, Oracle son obligatorios, pero potencialmente se podría utilizar otros.
- Trabajo con ORM. Inicialmente se previó utilizar EF Core, pero en la etapa de diseño estaban dispuestos a considerar otros ORM.
- Autogeneración de migraciones. Dado que se está desarrollando en Code First, se desea evitar la necesidad de "escribir manualmente" las migraciones.
- Conflictos de versiones. En un entorno de desarrollo distribuido, al fusionar, EF Core puede fallar debido a conflictos. Esto se convierte en un problema significativo, ya que diferentes partes de la aplicación son creadas por diferentes desarrolladores, por lo que se pierde mucho tiempo en cada caso.
- Documentación y soporte desarrollados. Aquí, creemos que no se necesitan explicaciones.
- Gratuitidad. Este criterio es condicional, ya que también estaríamos dispuestos a considerar sistemas no muy caros o caros, pero perfectos en comodidad.
Como resultado de una pequeña investigación, se encontraron y reconocieron como deseables las siguientes opciones:
- Migraciones de EF Core
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Y ahora un poco más de detalle
Naturalmente, esta fue la primera y principal opción para elegir. Una herramienta nativa, que funciona directamente sin ninguna complicación. Una gran cantidad de documentación, tanto oficial como no oficial, facilidad, etc. Sin embargo, las críticas que se hacían al clásico EF son igualmente relevantes para EF Core.
Así que para EF Core se destacan las ventajas:
- Soporte de Microsoft, documentación, también en ruso, una enorme comunidad.
- Autogeneración de migraciones en base a CodeFirst.
- A diferencia de EF 6, en EF Core ya no se almacena una instantánea de la base de datos. Al trabajar con EF Core en Code First, ya no es necesario desplegar la base de datos.
- Dado que partimos de Code First, hay la posibilidad de mantener una única migración para todos los proveedores de acceso a datos requeridos.
- Con respecto a los proveedores, se soportan tanto PostgreSQL como Oracle, etc., y también – MS SQL Server 😊.
Y también los inconvenientes:
- La resolución de conflictos se ha mantenido en el mismo nivel. Es necesario establecer la secuencia de las migraciones y actualizar las instantáneas de la base de datos.
- Dependencia de los modelos en base a los cuales se generaron las migraciones.
DbUp
DbUp es una biblioteca en .NET que se instala a través de NuGet y ayuda a aplicar cambios en SQL Server. Rastrea qué scripts de cambios ya han sido ejecutados y ejecuta los que son necesarios para actualizar la base de datos. La biblioteca surgió de un proyecto de motor de blogs de código abierto en ASP.NET y existe bajo la licencia MIT, y su código está en GitHub. Las migraciones se describen utilizando T-SQL.
Cuáles son las ventajas aquí:
- Soporte para una gran cantidad de bases de datos (MS SQL Server, PostgreSQL, MySQL).
- Dado que los scripts se escriben en T-SQL, son bastante simples.
- Los conflictos también se resuelven mediante SQL.
Y los inconvenientes:
- A pesar de la variedad de bases de datos soportadas, Oracle no está entre ellas.
- No interactúa con ORM.
- Escribir scripts en T-SQL 'manualmente' – no es lo que buscábamos.
- La documentación y la comunidad son más bien mediocres, aunque tal vez no sean necesarias para escribir scripts SQL.
RoundhousE
Esta herramienta de gestión de migraciones, distribuida bajo la licencia Apache 2.0, al igual que la anterior, funciona con el motor de migraciones T-SQL. Aparentemente, los desarrolladores se centraron en resolver problemas técnicos relacionados con el soporte de bases de datos, en lugar de crear un proceso de desarrollo cómodo.
Pros:
- Soporta las bases de datos necesarias (incluyendo Oracle)
Desventajas:
- Oracle (así como Access, que no es relevante para nosotros) no es compatible con .NET Core, solo con .NET Full Framework
- No funciona con ORM
- La documentación es incluso menor que la del anterior instrumento
- De nuevo, las migraciones se escriben mediante scripts
ThinkingHome.Migrator
Herramienta para la migración de versiones de esquemas de bases de datos para la plataforma .NET Core, distribuida bajo la licencia MIT. .
Pros:
- Está diseñado para .NET Core
- Se ha implementado una secuencia de migraciones ramificada
- Se ha implementado el registro de migraciones
Desventajas:
- La última actualización fue hace un año. Aparentemente, el proyecto no está siendo mantenido
- No se soporta Oracle (en el artículo se indica que esto se debe a la falta de una implementación estable para .NET Core, pero eso fue hace un año)
- No hay generación automática de migraciones
En general, el proyecto se ve prometedor, especialmente si hubiera evolucionado, pero necesitábamos tomar una decisión aquí y ahora.
Fluent Migrator
La herramienta de migraciones más popular, que tiene un gran número de aficionados. Se distribuye bajo la licencia Apache 2.0. Como se indica en la descripción, es una plataforma de migración para .NET, similar a Ruby on Rails Migrations. Los cambios en el esquema de la base de datos se describen en clases en C#.
Aquí hay ventajas:
- Soporte para las bases de datos necesarias
- Soporte para .NET Core
- Una gran comunidad activa
- Los conflictos de migraciones se resuelven de manera secuencial: se indica el orden de ejecución de las migraciones. Además, si hay un conflicto alrededor de una entidad, durante la fusión de código, su resolución se lleva a cabo de la misma manera que en el resto del código
- Hay perfiles que se ejecutan después de una migración exitosa. Y pueden contener funciones de servicio. La última actualización fue hace un mes, es decir, el proyecto sigue vivo.
En cuanto a desventajas, tenemos:
- No hay generación automática de migraciones
- No hay conexión con los modelos de EF
- No hay instantáneas de la base de datos
¿Cuál fue nuestra elección?
Los debates más acalorados giraron en torno a dos parámetros: la autogeneración de migraciones y la resolución razonable de conflictos. Otros factores generaban mucho menos temor. Al final, como resultado de la discusión, el equipo decidió utilizar Fluent Migrator en el nuevo proyecto. Esto se debe a que la resolución de conflictos a largo plazo traerá muchas más ventajas.
Conclusiones
Por supuesto, no existen herramientas perfectas. Así que tuvimos que establecer prioridades en nuestras "deseos". Sin embargo, para otros equipos y otras tareas, otros factores pueden ser decisivos. Esperamos que este artículo les ayude a tomar una decisión.
Fuente: habr.com
