Integración continua con First Migrations del código EF

Question

Me preguntaba si podría automatizar completamente las primeras migraciones de código para la integración continua.

Actualmente mi integración continua simplemente simplemente actualiza los cambios en el código, sin embargo, yo manualmente generar una migración y actualizar la base de datos en mi servidor de integración continua.

¿Es confiable/posible/recomendado generar las migraciones y actualizar la base de datos automáticamente?

Por ejemplo:

tengo ID de usuario del usuario con la propiedad y nombre de usuario. Luego agrego una edad de propiedad en el código. El escenario actual me obligaría a crear una migración que capturará este cambio, y luego verifico mis cambios en el control de la versión. La integración continua detectará este cambio y desplegará la nueva versión. Tengo que actualizar manualmente la base de datos (que debe ser automática).

¿Puedo omitir la generación de migración también, de modo que simplemente puedo agregar la antigüedad de la propiedad en el código y la integración continua generará esta migración. No estoy seguro de si esto es recomendado.

Answer 1

Parte de la integración continua también es la posibilidad de deshacer los malos cambios si no pasan las pruebas.

• ¿Escribes los scripts de actualización de la base de datos de una manera que también se pueden degradar?
• ¿Crea algunos puntos de guardado o copias de seguridad para cada confirmación?
• ¿Perderá datos en la base de datos en caso de copia de seguridad/restauraciones en compromisos incorrectos?
• ¿Cuál es el mal cambio en el DDL?

Esas son algunas de las preguntas que debe considerar antes de implementarlo.

Answer 2

La respuesta es sí, pero no del todo como se describe.

Debe y debe generar manualmente la migración. No todas las migraciones pueden crearse automáticamente, y en esos casos, es necesaria la modificación manual de la migración generada. División de columna, ciertos tipos de cambios de tipo de datos, etc.

Su servidor de CI puede entonces aprovechar migrate.exe para sincronizar sus bases de datos con su modelo. La parte difícil es manejar las migraciones que resultan en degradaciones. Por lo tanto, pasar de v1 a v2 es fácil, pero de v2 a v1 es más complicado ya que solo el ensamblado v2 sabe cómo "volver" a v1.

Terminé creando una herramienta personalizada que ejecutaba migraciones de forma inteligente y automática determinaba qué ensamblaje de modelo (contexto) usar para la migración. Puede hacerse una idea de cómo hacerlo aquí: EF Code First Migrations to Deploy Older Version

El resultado final es que puedo verificar un cambio de modelo/migración y saber que mi cambio de db se implementará automáticamente en cualquier entorno que sea parte de mi ci/cd pipeline - y sí, eso incluye absolutamente la producción.