none
Actualizaciones usando Database first RRS feed

  • Pregunta

  • Muy buenas,

    lo primero es que no tengo muy claro si hacer esta pregunta aquí o en el foro de asp.net mvc.

    Os pongo en situación.

    Tengo una aplicación desarrollada usando ASP.NET MVC 5 y EF 6.

    A la hora de empezar el proyecto se optó por usar database first ya que teníamos el esquema de la base de datos en SQL server.

    Actualmente la aplicación está en producción y ahora es cuando nos surgen las dudas con respecto a los nuevos desarrollos en la aplicación que requieren actualizaciones en la base de datos.

    El equipo de desarrollo se ha creado nuevas tablas en la base de datos y ha cambiado algunos campos, ha actualizado el modelo en la DALy han empezado con el desarrollo (controladores, vistas.....)

    ¿Como gestionáis esto para ponerlo en producción?

    Mi primera idea ha sido parar la aplicación, ejecutar los scritps de sql para hacer las modificaciones en la base de datos, publicar la nueva versión de la aplicación y arrancarla otra vez, pero pienso que tiene que haber otra manera de hacerlo.

    Gracias de antemano

    miércoles, 1 de febrero de 2017 15:37

Respuestas

  • Mi primera idea ha sido parar la aplicación, ejecutar los scritps de sql para hacer las modificaciones en la base de datos, publicar la nueva versión de la aplicación y arrancarla otra vez, pero pienso que tiene que haber otra manera de hacerlo.

    Efectivamente, esa es la forma sencilla de hacerlo. El problema es que mientras haces el cambio, la aplicación está parada y no da servicio a los usuarios. Si necesitas que la aplicación funcione continuamente sin interrupción, entonces no hay ningún procedimiento universal, sino que hay que pensar cada cambio individualmente.

    Por ejemplo, si en una tabla necesitas quitar un campo y poner otro, entonces lo primero haces un "alter table... Add..." para añadir el campo, cosa que se puede hacer sin parar la aplicación, y a la aplicación no le debería molestar que haya un campo de más si está bien hecha. Después se actualiza la aplicación, instalando la versión que usa el campo nuevo y no usa el antiguo. Para que los usuarios no noten interrupción, se paran parte de los servidores de la granja, se actualizan, se vuelven a poner en marcha, y luego se repite con el resto de la granja. Y una vez que ya está en marcha esa versión, se hace el "alter table" que elimina el campo viejo.

    Y de la misma manera, si hay más cambios en la base de datos, cada uno de ellos debe planearse cuidadosamente para que se pueda hacer de una manera similar sin que la aplicación deje de funcionar en ningún momento. Evidentemente es algo muy costoso de hacer; es uno de los problemas que tienen las aplicaciones que deben funcionar permanentemente sin ninguna interrupción.

    • Marcado como respuesta .damorcor martes, 21 de febrero de 2017 14:13
    miércoles, 1 de febrero de 2017 21:24

Todas las respuestas

  • Mi primera idea ha sido parar la aplicación, ejecutar los scritps de sql para hacer las modificaciones en la base de datos, publicar la nueva versión de la aplicación y arrancarla otra vez, pero pienso que tiene que haber otra manera de hacerlo.

    Efectivamente, esa es la forma sencilla de hacerlo. El problema es que mientras haces el cambio, la aplicación está parada y no da servicio a los usuarios. Si necesitas que la aplicación funcione continuamente sin interrupción, entonces no hay ningún procedimiento universal, sino que hay que pensar cada cambio individualmente.

    Por ejemplo, si en una tabla necesitas quitar un campo y poner otro, entonces lo primero haces un "alter table... Add..." para añadir el campo, cosa que se puede hacer sin parar la aplicación, y a la aplicación no le debería molestar que haya un campo de más si está bien hecha. Después se actualiza la aplicación, instalando la versión que usa el campo nuevo y no usa el antiguo. Para que los usuarios no noten interrupción, se paran parte de los servidores de la granja, se actualizan, se vuelven a poner en marcha, y luego se repite con el resto de la granja. Y una vez que ya está en marcha esa versión, se hace el "alter table" que elimina el campo viejo.

    Y de la misma manera, si hay más cambios en la base de datos, cada uno de ellos debe planearse cuidadosamente para que se pueda hacer de una manera similar sin que la aplicación deje de funcionar en ningún momento. Evidentemente es algo muy costoso de hacer; es uno de los problemas que tienen las aplicaciones que deben funcionar permanentemente sin ninguna interrupción.

    • Marcado como respuesta .damorcor martes, 21 de febrero de 2017 14:13
    miércoles, 1 de febrero de 2017 21:24
  • Gracias por la respuesta Alberto.

    La verdad, pensaba que habia algun procedimiento estardar para hacer este tipo de cosas.

    He seguido leyendo sobre el tema y este articulo me ha parecido muy interesante

    https://msdn.microsoft.com/es-es/library/ee210546.aspx

    aunque no he sido capaz de usarlo. Al final siempre tengo el mismo problema al crear nuevos campos vinculados a otras tablas que no admiten valores nulos.

    martes, 21 de febrero de 2017 14:13