¿Debería versionar aplicaciones web?

Recientemente tuve una discusión con un compañero de trabajo sobre el control de versiones de aplicaciones web.

No creo que lo necesite en absoluto, y si solo desea un control de cordura para confirmar que su último lanzamiento esté en vivo, creo que una fecha (YYMMDD) probablemente sea lo suficientemente buena.

¿Estoy fuera de la base? ¿Me estoy perdiendo el punto? ¿Debo usar los números de versión de la aplicación web?

Si revende la misma aplicación web a varios clientes, absolutamente debe versionarla.

Si se trata de un sitio web que solo se instaló en una ubicación, la necesidad es menos grave, pero aún así no podría doler. Sería menos susceptible a los problemas de zona horaria y demás. Diagnosticar un problema en una versión de biblioteca 1.0.2.25 es mucho mejor que buscar la compilación de la biblioteca el 3 de noviembre de 2010 a las 11:15 a.m.

Si puede automatizar el número de versión en las DLL de su aplicación, no podría hacer daño. Le ayudará a realizar un seguimiento de las versiones.

En general, las aplicaciones web se lanzan solo en una ubicación donde la está alojando, por lo que no es tan importante como decir una aplicación de escritorio. Puede ayudar con las reversiones, el seguimiento de errores (es decir, en qué versión estaba presente) y hacer un seguimiento de la diferencia entre los servidores de desarrollo, preparación y producción, si corresponde.

Buscaría automatizarlo: es el tipo de cosa que puedes configurar una vez y usarlo si lo necesitas.

A sus usuarios no les importan los números de versión, ya que siempre tienen la última y mejor versión de todos modos, pero se lo deben a usted (y a su equipo) saber exactamente qué versión se está ejecutando en vivo. Finalmente, su fuente de desarrollo se desincroniza con el código en vivo y definitivamente debe saberlo. Así que etiquete sus lanzamientos en su árbol svn / git y marque la aplicación web con esa etiqueta.

Si tiene instancias de desarrollo / prueba, es bastante importante que los miembros del equipo del proyecto puedan ver qué compilación / revisión están probando.

Además de lo que han dicho los demás, agregaría que el control de versiones también es importante desde una perspectiva de marketing. Una nueva versión es algo nuevo que se puede comercializar a clientes potenciales o existentes. Les permite a los clientes saber que algo es 'nuevo' y ver que las cosas están avanzando. Proporciona agradables agrupaciones de nuevas características. Y se ve más profesional.

Digo que para cualquier cosa que no sea una aplicación web trivial, debe versionarla. Hay dos nociones ligeramente diferentes en el trabajo aquí:

1. aplicación en su conjunto
2. archivos individuales

Independientemente de la situación, creo que los archivos deben tener números de versión (o revisión) individuales. Idealmente, esto sería manejado de forma automática por su sistema de control de versiones. Como lo han dicho otros, es más fácil referirse al número de versión de un archivo que a su fecha y hora.

Si tiene (o puede tener) más de una instalación en vivo de la aplicación, debe versionarse como un todo. Esta también es una buena práctica si tiene entornos de desarrollo y prueba separados (como probablemente debería). El número de versión de cada aplicación (o versión) se refiere a una colección de archivos individuales con números de versión específicos. Si bien lidiar con todo esto es una carga adicional, es más fácil retirar una versión específica que archivos individuales con números de revisión específicos.

Esto me hace pensar en una noción en lingüística. Se dice que si no puede expresar algo en un idioma, no puede pensarlo (en ese idioma). Pienso en la palabra alemana 'Schadenfreude'. Es mucho más fácil pensar (y hablar) en esta noción de "sentir alegría debido a la desgracia de otra persona" al referirse a esa palabra que a su definición. Esa es la razón por la cual la palabra se ha introducido en el idioma inglés.

Del mismo modo, los números de versión hacen que sea más fácil hablar (y pensar) de su aplicación y sus archivos en estados específicos. Si usted es un equipo de una sola persona, trabajando en una sola aplicación, probablemente no haga una gran diferencia. Sin embargo, a medida que las cosas se complican, es mejor que tenga estas etiquetas disponibles para su uso.

Debe versionar su aplicación web con la identificación de compilación de su servidor de compilación y tener esa identificación incluida en todos los informes de errores.

Esto le permitirá retroceder en el tiempo en caso de que tenga que corregir un error reportado en una versión anterior que actualmente no está presente en producción.

De su pregunta, queda claro que tiene en mente una aplicación web simple

• Solo accesible mediante una GUI web y no mediante una API web (-servicio) . Si tiene usuarios que acceden a la aplicación utilizando una API, debe versionarla. Si cambia la API, interrumpe los clientes, por lo que debe mantener una versión diferente de la API al mismo tiempo.

• Solo se ejecuta una instancia a la vez . Incluso si solo tiene el tipo web, si tiene más instalación necesita saber qué cliente está ejecutando qué versión.

• Con tiempo de inactividad aceptable para la actualización de la versión en vivo. Existe posiblemente un gran problema que es la base de datos . Los cambios importantes con las versiones más nuevas vienen con cambios en la estructura subyacente de los datos. Si solo tiene una versión ejecutándose en ese momento, probablemente tendrá que apagar la versión anterior, actualizar la base de datos y encender la nueva versión. Lo que resulta en tiempo de inactividad de la aplicación. Esto puede ser aceptable dependiendo del número y tipo de usuarios.

• ¿Uso interno solo con base de instalación limitada?
• ¿O es probable que tenga múltiples versiones en la naturaleza?

Solo tenemos el primero, así que solo use el número de versión para verificar la cordura después del lanzamiento. No tenemos que rastrear muchas versiones en uso al mismo tiempo.

Si su aplicación web consta de múltiples módulos, tanto en el cliente como en el servidor, cada módulo debe ser versionado. Y cada combinación de versiones de módulos tanto en el cliente como en el servidor debe tener una identificación única, una identificación que debe estar presente en todos los mensajes de registro y error.

Al usar esa convención, siempre será posible recrear el estado en que se encontraba la aplicación web en un momento dado.

En mi opinión, dado que las aplicaciones web en estos días se crean utilizando lenguajes dinámicos en ambos lados, servidor y cliente, no debería haber ninguna razón para volver a cargar una aplicación web actualizada a menos que el usuario reinicie el navegador o recargue manualmente la página.

Solo las partes o módulos actualizados en la aplicación web deben volver a cargarse sin afectar el estado general de la aplicación.

¿Por qué podrías preguntar? Bueno, al hacer cumplir eso, la aplicación web será, por su diseño, más robusta, correcta y probablemente más fácil de mantener. Si la aplicación web siempre requiere una actualización simultánea del servidor / cliente, entonces probablemente no esté construida de la manera correcta.

¡Sí, deberías versionarlo! Y debería haber una etiqueta en su sistema de control de revisión (como subversion, git, mercurial, etc.) que coincida con el número de versión.

La etiqueta te permite regresar y hacer una rama. Por ejemplo: la versión de producción actual tiene un error, pero no puede solucionarlo porque el código en su máquina simplemente no está listo para salir. Sin embargo, si lo tiene etiquetado en su RCS, puede bifurcarse en esa etiqueta y corregir el error en la versión exacta del código que se ejecuta en producción.

Personalmente, creo que debería versionar de todos modos, pero una gran ventaja de versionar aplicaciones web que es específica para sitios web es que puede hacer que los cambios en el contenido estático sean mucho más fáciles de administrar.

Por ejemplo, supongamos que tiene un archivo mysite.css que tiene una fecha de vencimiento futura (lo que generalmente desea hacer para que esté en caché en el navegador en cada página). Si luego cambia un estilo en ese archivo, nadie que haya estado en su sitio antes lo verá a menos que hagan algo para borrar ese archivo de su caché.

Si está versionando su sitio, podría cambiar todas las referencias de CSS en su compilación a algo como mysite.css? V = 1234, lo que le permitirá mantener la fecha de vencimiento en el futuro lejano y no preocuparse por cambios futuros como en la próxima compilación. será mysite.css? v = 1235.

Si deberías. Por razones de distribución señaladas aquí por otras respuestas.

Pero ya veo, por qué haces la pregunta. El enfoque de las aplicaciones web depende de los costos. Es opuesto al enfoque retráctil heredado, donde los costos incluyen medios físicos, distribución, instalación, copia impresa de la documentación, capacitación y soporte técnico. Cualquier cosa que pueda ser excluida, debe ser excluida.

Para ser claros, supongo que está hablando de un número de versión visible para el usuario de algún tipo, y no renuncia al control de versiones en el desarrollo. (si cree que no necesita control de versiones en desarrollo, entonces está equivocado, necesita control de versiones).

Para un proyecto de un solo host no es estrictamente necesario, porque si surge alguna pregunta, siempre puede mirar el host y confirmar lo que realmente está funcionando. Sin embargo, es bastante agradable, porque puede ser útil una o dos veces. Realmente depende de usted si cree que será útil o no.

Para un proyecto con múltiples hosts, no es realmente opcional. Eventualmente, los diferentes hosts terminarán con diferentes versiones y deberá poder distinguirlos al final del usuario.