¿Cómo aborda la gestión de versiones para una aplicación web (SaaS)?

Question

¿Cuál es el mejor enfoque para lanzar una nueva versión de una aplicación web alojada y con qué frecuencia sueles lanzarla? ¿Elige una fecha arbitraria, digamos cada semana, mes, etc. para implementar un conjunto de arreglos acumulados (quizás utilizando un enfoque similar a Acercamiento de Joel a las fechas de envío )? Esperar mucho más que eso parece vencer parte de la gran ventaja de una aplicación alojada. Por otro lado, no querrá implementar constantemente nuevas características que puedan confundir al usuario (es decir, si hubiera algo diferente cada vez que iniciara sesión).

Hasta hace poco, mi experiencia ha sido principalmente con aplicaciones de escritorio o de servidor instaladas. Tengo curiosidad por ver qué tipo de gestión de lanzamiento usa la gente con una aplicación alojada.

Answer 1

El enfoque de Google es probablemente el mejor para el usuario final, pero tiene el costo de la complejidad.

Lanzan nuevas versiones (y, a veces, solo cambios individuales) de forma bastante constante (tan a menudo como a diario, según el proyecto). Pero aquí está el truco: solo una pequeña porción de usuarios recibe la nueva versión.

Google tiene una gran cantidad de usuarios para sus grandes productos, por lo que es práctico establecer reglas como "el 5% de los usuarios deberían ver esta función".

Luego pueden analizar los resultados y planificar su próxima versión, quizás para otro 15% de la población de usuarios.

Answer 2

Por mucho que los ingenieros quieran definir una rutina para vivir, realmente va a estar impulsada por las demandas comerciales detrás del sistema. También depende de la naturaleza de las actualizaciones, etc. ...

Las actualizaciones de contenido y HTML no deberían ser un gran problema para impulsar. Los cambios en la aplicación DEBEN ser un gran problema y seguir las rutinas de prueba establecidas en un sitio de vista previa antes de que se publique en vivo.

Una cosa segura es que necesita tener una muy "limpia" forma de implementar (y deshacer) los cambios. También necesita un " fácil " forma de revisar y auditar los cambios antes de que se publiquen.

Usando una mezcla de " git " y "rsync" nos permite un control total sobre el proceso. Todos los cambios en nuestro proyecto se desarrollan en una rama que se ramificó a partir de la "Producción" rama. Antes de que se activen los cambios, la " Producción " la rama debe estar completamente fusionada. El acto de poner en marcha es simplemente fusionar la rama apropiada en "Producción". y rsyncing a los servidores en vivo. Git hace esto realmente fácil.

Esto garantiza que los cambios que se realicen no puedan entrar en conflicto con otros cambios en curso.

Desde la adopción de este sistema, nuestra rutina de implementación ha aumentado dramáticamente en eficiencia y claridad. Y, por cierto, nuestras implementaciones varían desde varias veces al día hasta una vez cada varios meses. Todo depende. Preferiría un ciclo de lanzamiento 1-2 por semana en un proyecto activo.

Answer 3

Salir temprano y con frecuencia es lo que hago, y lo que hacemos donde trabajamos. También blogueamos sobre nuestras actualizaciones cada vez que las hacemos. Probablemente sea más fácil para usted si combina todas sus actualizaciones en una actualización a la vez (para control de calidad, tener que revertir, etc.) lo mejor que pueda. Desde la perspectiva del usuario, no creo que haya ningún problema con muchas actualizaciones. Mientras no sean malas actualizaciones. Creo que hay un problema si esperas un año entero o seis meses y obtienes todas tus actualizaciones en un gran lanzamiento. Eso es lo que mató un proyecto en el que solía trabajar (un lector de alimentación popular del que probablemente hayas oído hablar). La gente pensaba que estábamos muertos, y la percepción se hizo realidad. Nos abandonaron Así que estoy a favor de los horarios de lanzamiento de firehose.

Answer 4

Cada dos semanas debería ser suficiente, pero esto depende mucho de su mercado.

Answer 5

En Planbox (SaaS de gestión de proyectos ágiles basada en web) lanzamos todos los días. Podemos hacerlo porque la mayor parte de nuestra lógica de aplicación y toda nuestra lógica de presentación están en el front-end (Javascript). Incluso el HTML se genera a través de Javascript utilizando un motor de plantillas. Pero el backend (PHP) y su API REST rara vez cambian. Esto nos permite impulsar nuevas versiones del cliente en cualquier momento sin romper la compatibilidad.

Si puede pasar a dicha arquitectura, ahorrará toneladas de tiempo y obtendrá mucha eficiencia.