¿Cuáles son los peligros de usar migraciones EF (o cualquier marco de migración automática) en la producción?

Question

Estoy considerando utilizar las migraciones de Entity Framework 4.3 en un sitio de producción. Lo siguiente es mi preocupación:

Si la migración falla por cualquier razón, quiero que todas las declaraciones se retiren y el sitio se coloque en un estado hacia abajo para que ningún usuario pueda usar el sitio mientras intento solucionar el problema. Lo único es que no puedo volver a ejecutar los scripts a mano contra la base de datos ya que los archivos de migración se compilan en el ensamblaje. Podría realizar un seguimiento de los archivos de migración y los archivos de script SQL por separado, pero en ese momento por qué usar migraciones en absoluto.

En el trabajo, los archivos de script se almacenan en una carpeta SQL (a la que nadie puede navegar) en el sitio. Los archivos de Script de ejecución previamente se registran en la base de datos. Cuando aparecen nuevos archivos de script en la carpeta (y no están en la base de datos), si un usuario es un administrador, será redirigido a un portal de DB, de lo contrario, obtenga un sitio hacia abajo por mantenimiento. Si intentamos no ejecutar cualquier scripts desde el portal, tomamos los nuevos scripts e intentamos ejecutarlos manuales dentro de Express Studio. Esto ha funcionado durante más de una década. Solo estoy explorando migraciones para ver si ha llegado una mejor manera. No se siente así. Avíseme si hay una mejor manera y si no es migraciones, qué es.

Answer 1

Definitivamente no utilizaría migraciones automáticas en un entorno de producción. De hecho, soy demasiado fanático del control para usar migraciones automáticas. Prefiero las migraciones basadas en código para garantizar que todas las bases de datos (el entorno personal, de prueba, la producción de los desarrolladores) hayan pasado exactamente la misma secuencia de actualización.

Utilizando migraciones basadas en el código donde cada paso de migración obtiene un nombre, se puede generar un script de migración separado para su uso al levantar los entornos de prueba y prod. Preferiblemente debe ejecutarse en una copia de la base de datos para validar antes de ejecutarse en el entorno de PROD real.

Agregado más tarde

Para evitar que las migraciones EF hagan algo automático, se puede utilizar una estrategia de inicializador personalizada. Ver mi blog o el Implementación de las primeras aplicaciones del código EF a la base de datos de producción Pregunta de desbordamiento de pila.