Una versión grande o varios pequeños?

Question

Cuando estás trabajando en mejoras a una línea existente de aplicaciones de negocio, ¿cree que es mejor lote hasta cambios en versiones más grandes menos frecuentes, o continuamente envía nuevas características en versiones más pequeñas? Suponiendo que hay actualizaciones de hardware o actualizaciones de bases de datos, haces estos cambios con los comunicados también, o mantenerlos separados?

Liberar todo junto tiene la ventaja de que hay menos interrupciones en el negocio, y menos fuera de las horas de trabajo invovled, pero cualquier problema que más tarde encuentro podría ser debido a la actualización de base de datos, el hardware, o cualquier número de cambios de software.

La liberación de poco ya menudo hace que sea más fácil de localizar a los problemas resultantes de una autorización, pero conduce a una mayor disrupción y más pruebas de regresión pasado tiempo.

¿Qué es mejor?

Answer 1

Tenga en cuenta cómo cada versión afecta a los clientes. Se libera pequeñas frecuentes los hacen más feliz debido a la resolución de problemas críticos más rápido? ¿Esto mejorar sus ventas y reputación? Si se estimará cuidadosamente si estos beneficios outweight el trabajo extra que deben realizar, de lo contrario sólo tiene que seguir el camino que es más conveniente para usted.

Answer 2

En realidad depende del entorno de su En algunos escenarios:.

Muchos clientes : desea que todos los clientes tengan la misma versión, en la medida de lo posible. Es mucho más fácil tener grandes lanzamientos Anuales, semianual o trimestrales, como las pruebas y puesta en marcha de coordinación es muy costoso. En este caso me gustaría incluir cambios db también.

"Big infraestructura" : si se trabaja en un entorno de gran empresa con personell dedicado para los sistemas operativos y bases de datos, una vez más el costo total de un lanzamiento es grande y por lo tanto menos frecuentes lanzamientos más grandes son mejores <. / p>

En resumen, calcular los costos de un lanzamiento en mano de obra, INTERRUPCIÓN negocio, coordinación, poniendo a prueba y ponerla en relación con los beneficios de cada nueva característica o corrección de errores.

Por lo general tienden a tener 1-2 grandes lanzamientos al año y correcciones de errores entre medio de tapones de la demostración.

Answer 3

Creo que la mejor respuesta es: una mezcla de los dos.

Por ejemplo, si se ha añadido un poco de caramelo del ojo, o de hecho el nombre de texto más "AJAXy", o tal vez tiró en un nuevo tipo de informe - que esto sea lo libera "pequeños". Pronta liberación, y la liberación a menudo como sea posible.

Por otro lado, si ha cambiado un proceso de cara al usuario forzar a los usuarios a ser "nueva formación", o si está requiriendo cambios masivos de infraestructura -. Ir para un gran lanzamiento, y que esto sea lo menos posible

Como usted ha dicho, si hay poca o ninguna interrupción, hacer tan a menudo como sea posible, los usuarios van a ser la más feliz por ello - Y sí que estará pasando el tiempo menos en la prueba de regresión, ya que sólo tiene que probar todo lo relacionado a los cambios que ha realizado.

Answer 4

Creo que es mejor trabajar en una versión grande y remendar como sea necesario para corregir problemas en la línea.

Como desarrollador que necesita para anticipar posibles problemas y roturas en el sistema para que sea tan robusto como sea posible. Eso generalmente significa que tanto la prueba de antemano.

Ten en cuenta también que el usuario final puede no querer pagar por los incrementos más pequeños en el producto y pueden así esperar a que una gran actualización. Un buen ejemplo de esto es cuando llegué a Adobe Photoshop, que parecen lanzar una nueva versión cada año, así que se limitó a esperar hasta que pareció que era el momento adecuado

Answer 5

Un menor número de lanzamientos significa que va a ser la búsqueda de todos sus errores a la vez. Se hace más difícil saber qué cambio de código, que causó fallo. A continuación, tiene más de un problema con los insectos en cascada - un cambio de código que hizo hace meses ha causado un error, pero, mientras tanto, se han realizado otros cinco cambios que todo dependerá del error que presentó hace meses

.

Más pequeño, comunicados de alta calidad son mejores. comunicados de menor tamaño que sea más fácil para tener alta calidad.

Answer 6

En lo personal, estoy a favor de grandes lanzamientos.

Tengo un programa en el hogar, que presenta actualizaciones varias veces a la semana. Es muy molesto porque no hay una función de actualización automática, sólo una notificación de que hace volver.

Es posible que desee echar un vistazo a esta pregunta similar: con qué frecuencia soltar las actualizaciones de software

Answer 7

De hecho - ambos.
¿Puede el desarrollo posiblemente dividida en DESARROLL y LIBERACIÓN rama? Todas las cuestiones urgentes deben hacerse lo antes posible en la rama REL y se envían a los usuarios como una revisión. Después de aplicar la revisión en la rama REL, la necesidad de aplicar el parche sería enviado al equipo de DEV (nota: para corregir algún problema en REL usted tiene que escribir algo de código rápido, mientras que en la rama DEV tiene que poner algo de tiempo en replantear la solución propuesta , ya que las condiciones en la rama DEV podrían haber cambiado, por lo que es común que le escribe código completamente diferente para solucionar el mismo problema en la DEV o rama REL).
Cuando se llevará a cabo el desarrollo de la nueva versión, usted tiene que probar nuevas características y parches migrado de REL. Si todo está bien, usted será capaz de desplegar nueva versión grande, y archivar el DEV actual en REL, mientras el viejo REL será ahora sellada.