Sobre Migraciones con Entity Framework Core

Lo que vemos cuando guiamos una gran migración

Migraciones seguras en producción

Tras muchas horas con un cuaderno, Visual Studio y MS SQL MS abiertos y 12 migraciones a nuestras espaladas sólo para este proceso llegamos a un estado en el que nuestro dominio se acerca al ideal y las migraciones sólo nos obligan a ejecutar un pequeño script justo antes de la migración para recuperar unos ID’s y establecer el discriminador de nuestra TPH.

Además hemos usado nuestra infraestructura y entornos de desarrollo para ir probando todos estos pasos de una manera fácil. Por un lado hicimos una copia de la base de datos de producción para ir probando cada migración potencialmente peligrosa en desarrollo y por otro lado utilizamos otra copia de la base de datos de producción en Staging (pre-producción) para probar esa migración en bruto, toda seguida. No todo fue bien a la primera, no os voy a engañar, pero estábamos preparados para los fallos y ayer pudimos desplegar en producción con cuatro clicks y un ‘F5’ desde MS SQL MS.

Hasta ahí la historia de las migraciones. He puesto una captura de pantalla de mi carpeta Migrations en el proyecto donde tenemos el tema de la persistencia de Logtrip y no se ven todas, como dije, llegamos hasta 12. Hoy, con la mente fresca y renovadas energías, he decidido que todo este histórico nos sobra, y que podemos y debemos resetear el estado de las migraciones, es decir, movernos hacia tener una única migración a la que creo que llamaré v2_InitialMigration puesto que nos estamos moviendo hacia la versión 2 de Logtrip y nuestro MVP. 

Restablecer todas las migraciones

Hay bastante documentación al respecto, algunos artículos bastante obsoletos pues se refieren a EF y no a EF Core (por ejemplo  éste de West Wind, Resetting Entity Framework Migrations to a clean Slate) pero hoy vamos a utilizar la Documentación Oficial de Microsoft en la que podemos leer que lo siguiente:

In some extreme cases, it may be necessary to remove all migrations and start over. This can be easily done by deleting your Migrations folder and dropping your database; at that point you can create a new initial migration, which will contain you entire current schema.

It’s also possible to reset all migrations and create a single one without losing your data. This is sometimes called “squashing”, and involves some manual work:

• Delete your Migrations folder
• Create a new migration and generate a SQL script for it
• In your database, delete all rows from the migrations history table
• Insert a single row into the migrations history, to record that the first migration has already been applied, since your tables are already there. The insert SQL is the last operation in the SQL script generated above.

Es decir:

1. Eliminamos la carpeta migrations
   
2. Generamos una nueva migración:
   Lo que genera a su vez dos nuevos ficheros, uno con la migración y otro con el snapshot (la foto) de la estructura de nuestra base de datos 
   
   (Nótese que pese a que lo he eliminado y vuelto a generar este fichero LogtripDbContextModelSnapshot.cs es igual que el que había anteriormente, esto nos dará la confianza que necesitamos para continuar, tened cuidado de no llegar a esto pues algo habéis perdido por el camino)
3. Borrar todo el contenido de la tabla __EFMigrationsHistory:
   
4. Insertar esta nueva migración en la tabla de migraciones, para lo cuál podemos ejecutar:
    dotnet ef migrations script
   y reutilizar la última sentenciua SQL generada por ese comando:
   
5. Verificar que todo sigue funcionando como se esperaba y si es así.
6. Sube tu código y deja que corran tus pipelines:
7. Y ejecuta tu script (delete and insert en __EFMigrationsHistory) en cada despliegue de cada entorno.