Tengo la siguiente configuración en Windows Azure:Azure: Mejores Prácticas para las pruebas en un entorno de ensayo con el Código primeras migraciones
- Una "prueba" servicio alojado conectado a su propia base de datos de "prueba".
- Un servicio alojado de "producción" conectado a su propia base de datos de "producción".
Cuando una acumulación ha sido verificada en la prueba y está listo para ir a la producción, hacemos girar una implementación "puesta en escena" en el servicio de producción organizado, y hacer una prueba de humo rápida para asegurarse de que la nueva generación no es totalmente roto. La instancia de ensayo se implementa con los bits exactos que se implementarán en la producción, por lo que está hablando con la base de datos de producción. Cuando la escena es bendecida, presionamos el botón "VIP Swap" y la construcción está en producción. Todo es bueno.
El problema se produce cuando cambia el modelo de la base de datos. Tengo Code First Migrations funcionando perfectamente. Puedo agregar nuevas migraciones, aplicarlas localmente con la consola del administrador de paquetes y luego generar scripts SQL para actualizar la base de datos de prueba cuando presiono una nueva versión para probar. La pregunta es, ¿cuál es la mejor práctica sobre el uso de Code First Migrations junto con las implementaciones de etapas/producción? Cuando implemente una nueva compilación para organizar con cambios de modelo, espera encontrar una base de datos que coincida con su modelo. Pero luego si aplico los cambios del modelo a la base de datos de producción, la instancia de producción se queja porque su modelo no coincide.
Acabo de omitir la prueba de humo por etapas. Subo a la puesta en escena, luego actualizo la base de datos de producción y presiono el botón "Cambio de VIP" casi al mismo tiempo. Luego prueba humo en la producción. Si algo se rompe, "Swap VIP" vuelve y revierte los cambios en la base de datos.
¿Hay una manera mejor de hacer esto, o es eso más o menos?
Gracias!
estoy teniendo el mismo problema, lo único que se me ocurre en este momento es deshabilitar el automática "actualizar a la última", o ampliar mi propia DbMigrator si hay alguna forma de diferenciar entre puesta en escena y producción. La mejor manera sería apuntar a un archivo db de almacenamiento intermedio, que se podría permitir su actualización, y luego, cuando intercambie el objetivo con otro DB ... pero como nada realmente "sucede" cuando se intercambia, no puedo ver cómo debería suceder. – FRoZeN
Esto está realmente roto. La estadificación y las migraciones son incompatibles. No hay forma de migrar y calentar el servidor web de ensayo antes de intercambiar. El servidor web de producción baja tan pronto como se aplican las migraciones. Asumiría que el marco de la entidad podría manejar cambios progresivos (agregando una tabla por ejemplo). Parece que la única forma de hacerlo es con una base de datos de etapas separada. –