c# - para - ¿Está bien actualizar una base de datos de producción con migraciones EF?

update database force (4)

Según esta publicación de blog, la mayoría de las empresas que utilizan EF Migrations supuestamente no actualizan el esquema de base de datos de bases de datos de producción con migraciones EF. En cambio, el autor de la publicación del blog recomienda utilizar los scripts de actualización de Schema como parte del proceso de implementación.

He usado scripts de actualización de Schema durante algunos años y, mientras funcionan, estaba planeando usar migraciones de EF en el futuro por las siguientes razones:

Implementación más rápida, menos tiempo de inactividad
Un procedimiento de implementación más simple
Migración de datos existentes mucho más fácil de lo que sería posible con T-SQL
Una sintaxis más comprensible de los cambios a la espera de ser aplicados (clase DbMigration con sintaxis C # limpia versus script de migración T-SQL torpe en un entorno tradicional).
Existe una ruta de degradación fácil y rápida al antiguo esquema db si falla la implementación de la nueva versión del software

Una razón por la que puedo pensar que prohibiría el uso de EF para migrar un DB de producción sería si el esquema de DB solo fuera alterado por los DBA en lugar de los Desarrolladores. Sin embargo, soy DBA y desarrollador, por lo que esto no importa en mi caso.

Entonces, ¿cuáles son los riesgos de actualizar una base de datos de producción con EF?

Editar: me gustaría agregar que, como solomon8718 ya sugirió, siempre estoy sacando una copia nueva de la base de datos de producción a mi servidor de ensayo y pruebo las Migraciones EF que se aplicarán en el servidor de ensayo antes de aplicarlas a un servidor de producción. OMI, esto es esencial para cualquier actualización de esquema de un sistema de producción, ya sea que esté usando migraciones EF o no.

Bueno, intentaré responder de todos modos. Yo diría que no, no hay razón para no usar Code First Migrations en producción. Después de todo, ¿cuál es el punto de este sistema fácil de usar si no puede tomarlo por completo?

Los mayores problemas que veo con él son todos los problemas que puedes tener con cualquier sistema, que ya has notado. Mientras todo el equipo (incluido el DBA, si corresponde) está de acuerdo, creo que permitir que EF administre el esquema a través de migraciones es menos complejo y, por lo tanto, menos propenso a errores que la administración tradicional basada en scripts. Todavía haría una copia de seguridad antes de realizar una migración en un sistema de producción, pero de todos modos lo harías.

Tampoco hay nada que diga que un DBA no puede realizar una migración desde Visual Studio. El acceso aún podría bloquearse con privilegios en el nivel de la base de datos, y él / ella podría revisar la migración (en un útil formato de exportación SQL usando -Script , si lo desea) antes de realizar la operación real. Entonces todavía están en control, pero puede usar migraciones de código primero. Demonios, ¡incluso podrían terminar gustando!

Actualización: dado que los SPROC y TVF se mencionaron, también manejamos los que están en las migraciones, aunque en realidad se realizan con instrucciones SQL DbMigration.Sql() utilizando una llamada DbMigration.Sql() en Up() , y el reverso de ellas en el Down() (También puede usar CreateStoredProcedure y DropStoredProcedure para DropStoredProcedure simples, pero creo que aún tiene que definir el cuerpo en sí en SQL). Supongo que se podría decir que es una advertencia; Todavía no hay una forma de escribir una base de datos completa y completa únicamente en C #. Sin embargo, puede usar migraciones que incluyen scripts SQL para administrar todo el esquema. Un beneficio que hemos encontrado de este proceso es que puede usar el archivo de configuración de C # para los nombres de objetos de esquema (diferentes nombres de servidor para producción frente a desarrollo, por ejemplo) con un String.Format simple, combinado con la Transformación XML para los propios archivos de configuración.

Lo uso en producción para un par de proyectos. Una vez que lo domines creo que está bien.

Durante el desarrollo puede mantener activadas las migraciones automáticas, pero al final puede conectarse a la base de datos en vivo directamente desde la consola del administrador de paquetes y generar una migración. Le dará una migración para todos los cambios.

Pero siempre use siempre la opción -script con update-database y active el SQL usted mismo.

También recomendaría no usar la opción de actualización de db desde la implementación web. De esa manera no hay forma de saber cuánto de la migración ya se ha disparado por error. He tenido problemas con eso algunas veces. Lo mejor es obtener el SQL y dispararlo manualmente.

Otra advertencia que encontré: si tiene varios sitios web que usan el mismo contexto de datos, debe asegurarse de que todos estén actualizados al mismo tiempo. De lo contrario, podría haber una lucha constante de actualización / degradación de la base de datos entre los sitios web. Aparte de eso, funcionó bien para mí.

EDITAR: Mi propia perspectiva un año después de comenzar a usar EF Migrations en producción:

EF Migrations es realmente genial, incluso para uso en producción, siempre que

Probar las migraciones en un sistema de preparación. Pruebo todas las migraciones migrando completamente hacia abajo y hacia arriba en mi servidor CI antes de ejecutar pruebas de integración.
No active las migraciones automáticamente, sino con un archivo por lotes que inicia un administrador. Esto es esencialmente lo mismo que ejecutar el sql para una migración manualmente en SSMS.

Sí, hay buenas razones para no utilizar un sistema automatizado como Code First Migrations para realizar cambios en la base de datos de producción . Pero como siempre hay excepciones a las reglas.

Una razón que se ha mencionado serían los permisos de acceso, que estarían directamente relacionados con las reglas de gestión de cambios y las políticas de seguridad de su organización.
Otra razón sería su nivel de confianza en la herramienta Migraciones en sí. ¿Estamos seguros de que la herramienta no tiene un error? ¿Qué sucede si la herramienta falla a la mitad? ¿Está seguro de que tiene copias de seguridad actualizadas y un proceso para deshacer si es necesario?
Los scripts de cambio pueden ejecutar scripts inesperados o ineficientes. He experimentado casos en los que el sql generado copió los datos en una tabla temporal, soltó la tabla original y luego recreó la tabla original para cosas como agregar una nueva columna si cambia accidentalmente (o deliberadamente) el orden en que aparece la columna, o cuando cambias el nombre de la tabla. Si hay millones de registros involucrados, esto podría causar serios problemas de rendimiento.

Mi recomendación:

Suponiendo que tiene una base de datos provisional que refleja su esquema de producción, use la herramienta Migraciones para generar sus scripts de cambio en ese sistema. Por lo general, restauramos nuestra base de datos de escenario desde una copia de producción nueva antes de ejecutarla. Luego examinamos los scripts de cambio manualmente para verificar si hay problemas. Después de eso, ejecutamos los scripts en nuestra base de datos de escenario para asegurarnos de que se ejecute correctamente y que todos los cambios esperados ocurrieron. Ahora estamos seguros de que los scripts son seguros para ejecutarse en producción y realizar los cambios esperados. Este proceso abordaría los tres problemas que enumeré anteriormente.