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

Sí hay buenas razones no para usar un sistema automatizado como Migraciones de Código Primero para hacer cambios en la base de datos producción. Pero como siempre hay excepciones a las reglas.

1. Una de las razones 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.

2. Otra razón sería su nivel de confianza en la herramienta de migraciones en sí. ¿Estamos seguros ¿la herramienta no tiene un error? ¿Qué sucede si la herramienta falla a mitad de camino? ¿Está seguro de que tiene copias de seguridad actualizadas y un proceso para revertir si es necesario?

3. 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 accidentalmente (o a propósito) cambia el orden en el que aparece la columna o cuando cambia el nombre de la tabla. Si millones de registros están involucrados, esto podría causar graves problemas de rendimiento.

Mi recomendación:

Suponiendo que tiene una base de datos provisional que refleja su esquema de producción, utilice la herramienta Migraciones para generar sus scripts de cambio en ese sistema. Por lo general, restauramos nuestra base de datos stage a partir de una copia de producción nueva antes de ejecutarla. A continuación, examinamos los scripts de cambio manualmente para comprobar si hay problemas. Después de eso ejecute los scripts en nuestra base de datos stage para asegurarse de que se ejecuta correctamente y que todos los cambios esperados tuvieron lugar. Ahora estamos seguros de que los scripts son seguros para ejecutarse en producción y realizar los cambios esperados. This process would address all three issues I listed above.

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

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

EF Migrations es en realidad bastante genial, incluso para uso de producción, siempre que

1. Pruebe las migraciones en un sistema de estadificación. Pruebo todas las migraciones migrando hacia abajo y hacia arriba de nuevo en mi servidor CI antes de ejecutar las pruebas de integración.
2. No desencadene migraciones automáticamente, sino con un archivo por lotes que es lanzado por un administrador. Esto es esencialmente lo mismo que ejecutar el sql para una migración manual en SSMS.

Lo uso en producción para un par de proyectos. Una vez que te acostumbras, 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 siempre use la opción -script con update-database y ejecute el SQL usted mismo.

También aconsejaría no usar la opción actualizar base de datos de web deploy. De esa manera no hay manera de saber cuánto de la migración ya se ha disparado por error. Me he metido en problemas con eso un par de veces. Así que lo mejor es obtener el SQL y dispararlo manualmente.