Cómo actualizar con seguridad un sitio web en vivo

Question

Tenemos un sitio web basado en Django bastante simple para realizar operaciones CRUD. He estado haciendo pruebas y desarrollos localmente y luego revisando las versiones y los cambios en el esquema de la base de datos en el servidor en vivo una vez que se realizan las pruebas. Recientemente hemos tenido un problema al lanzar algunos tipos de cambios. Imagine la siguiente secuencia de eventos:

1. usuario abre un formulario web
2. sitio se actualiza para requerir nuevo campo en este formulario
3. usuario envía el formulario que han estado trabajando en
4. servidor devuelve un error porque esperaba recibir el nuevo campo que se agregó en el paso 2

¿Cómo manejan otros sitios este tipo de problemas? Mis ideas:

• Lleve el sitio fuera de línea mientras se realizan las actualizaciones. Esto realmente no resuelve el problema, porque un usuario puede tener un formulario web abierto durante un tiempo infinito antes de enviarlo, pero después de un cierto período de tiempo, es poco probable que alguien envíe el formulario.
• Realice actualizaciones automáticas en tiempos de tráfico muy bajos. Nuevamente, esto no soluciona realmente el problema, pero nuestro sitio no es tan popular y si hiciéramos una actualización a las 3: 00a dudo que hubiera muchos usuarios. Una preocupación con esta técnica son las actualizaciones automáticas que fallan.
• Formularios de control de versiones para que el servidor reconozca que se envía un formulario anterior y proporciona una respuesta más fácil de usar. ¿Hay herramientas automatizadas que podrían ayudar con esto?

¿Pensamientos?

Answer 1

No veo cómo podría lograr esto sin codificar en su validación la posibilidad de que se haya producido una actualización. p.ej. "Anticipando" que los campos pueden haber cambiado al enviar y al configurar los valores predeterminados/rechazar en consecuencia.

¿Qué pasa con la "reducción" de la presentación de contenido a medida que se acerca la ventana de mantenimiento, para reducir al mínimo los usuarios afectados a los que han dejado abiertos sus navegadores?

Answer 2

Si realmente es un gran problema, podría incluir la versión del código como un tipo de variable oculta en cada uno de sus formularios. Si la versión enviada no coincide con la versión actualmente en ejecución de la aplicación, podría mostrar un error adecuado e indicarles que completen los campos nuevos que puedan existir en el formulario. Incluso podría ir un poco más allá y solo mostrar los mensajes cuyo formulario ha cambiado. Posiblemente crear algún tipo de hash basado en la definición de la forma, y ​​usar eso como el campo oculto. Si el hash es incorrecto, sabes que están enviando un formulario incorrecto.

Answer 3

Los cambios a una API publicada (o IU, en este caso) siempre son complicados. Si es posible, preserve la compatibilidad hacia atrás. Para la mayoría de los formularios, reconozco que la funcionalidad no cambiará entre versiones. Puede agregar o eliminar un campo o dos, pero eso sería manejado por la validación del formulario en el back-end. Eso es esencialmente lo que estás describiendo en tu paso 4. Realmente no considero que sea un gran problema; Los errores de tiempo de ejecución ocurren de vez en cuando: siempre que su aplicación lo maneje correctamente e informe al usuario del problema, entonces realmente no hay problema.

Answer 4

Hay muchos sitios que uso (concedidos, en su mayoría internos a mi lugar de trabajo) que anuncian algo así como: "Estaremos fuera de servicio este fin de semana de 6:00 p.m. Sábado a 6:00 a.m. del domingo por la mañana Por favor planee estar fuera del sistema en ese momento ". Si bien no es perfecto, nada lo es, y parece un buen enfoque. Solo deja tiempo suficiente para sacar las cosas nuevas, pruébalas y vuelve a las viejas si es necesario. Si cree que es necesario, siempre puede configurar una página simple que diga "Lo sentimos, no estamos disponibles ahora" y dirigir a la gente a eso durante el tiempo de inactividad. En general, nadie se quejará si no necesita todo el tiempo que declaró originalmente y está haciendo copias de seguridad temprano (tal vez los vagabundos que quieren una excusa para evitar el trabajo serían la excepción, pero probablemente no estén trabajando de todos modos).

Answer 5

La forma "correcta" de hacerlo es tener vistas bien definidas que manejen esta clase completa de fallas con elegancia. En el caso de agregar un nuevo campo al modelo que se requiere (estoy suponiendo que eso es lo que está sucediendo), la vista debería lidiar con eso con una excepción ValidationError que arroja un mensaje de error amigable y envía al usuario de vuelta al formulario (que , cuando se vuelva a cargar, debería tener el nuevo campo disponible). No importa qué campos se agreguen al modelo, la excepción generará un error de limpieza y enviará al usuario de regreso.