¿Política sobre versiones de mantenimiento frente a versiones normales?

Question

Mi empresa está luchando con la cuestión de las versiones de mantenimiento en comparación con las versiones "normales", en el contexto de una aplicación instalada en el sitio en grandes organizaciones que pagan por soporte. Primero permítame definir mis términos:

• Imagine que hemos lanzado las versiones 1.0, 1.1 y 1.2 del producto. Esto es lo que llamo "normal" lanzamientos, es decir, son el próximo lanzamiento de la rama principal de desarrollo, que incorpora todas las correcciones y mejoras de errores más recientes y mejores (posiblemente decenas de cada versión).
• Ahora imagina que un cliente importante en 1.0 informa un problema que nadie ha visto antes. El problema todavía existe en 1.2, y desafortunadamente 1.3 no estará disponible por varias semanas o meses. Así que ramificamos nuestro código en 1.0 para crear una versión 1.0.1 "maintenance", que contiene solo el cambio que soluciona el problema.

Este enfoque satisface al cliente porque solucionamos el problema en un día o así, en lugar de esperar semanas hasta la próxima versión normal. Además, dado que la versión de mantenimiento solo contiene un pequeño cambio, no necesitan pasar por un proceso extenso de UAT, mientras que si se actualizan a la siguiente versión normal, que podría tener varias versiones, recibirían quizás 30 o 40. cambios de producto que (en su opinión de aversión al riesgo) requieren una UAT extensa.

El problema es que:

• Es costoso para nosotros para crear y soportar múltiples versiones de nuestro software
• Permite stick-en-el-barro clientes caigan demasiado lejos detrás de la última versión
• Complica el proceso de actualizar eventualmente esos clientes en el futuro, ya que su instalación es sutilmente diferente de la de cada otro cliente 1.0 (la actualización de su base de datos es particularmente complicada si la versión de mantenimiento lo cambió)

Entonces, me preguntaba ¿cuál es la postura de todos los demás sobre este tema? ¿Cómo puede mantener feliz al cliente sin hacer una barra por su cuenta a través de una proliferación de versiones de mantenimiento? Por ejemplo, ¿permite que se realicen algunas categorías de arreglos como una versión de mantenimiento, pero insiste en que se hagan otros tipos en la próxima versión normal?

Aclaración: escribir software sin errores no es una solución total, porque un "problema" en el contexto anterior podría ser un cambio imprevisto en el comportamiento de un sistema externo del que depende nuestro producto.

Answer 1

Creamos un solo lanzamiento para nuestros clientes, y nosotros construimos diariamente y prueba de unidad (que hacer tienen tanto, ¿no?)

Con estos dos que más o menos podemos empujar nuestra código tan frecuente como queramos, por lo que no hay necesidad de preocuparse por la liberación de mantenimiento o la versión normal. Solo hay una copia que vale la pena usar, y esa es la última copia.

Editar: Cuando se trata de la situación "OMG nuestra función es la mitad del camino, pero todavía tenemos que liberar ahora y sí me refiero a EMPRESA! "lo que haríamos es etiquetar la nueva característica (usando preprocessor directive) y asegurarnos de que durante la construcción, todo el código dentro de la etiqueta simplemente se comente.

Answer 2

El cliente es lo primero. Tendré que aguantar soportando múltiples versiones de tu software, porque algunos clientes simplemente no se actualizarán. Es un hecho molesto. Puedes mitigarlo en algunas áreas del desarrollo de software (p. ej., aplicaciones web, cualquiera que todavía ejecute la versión original). de gmail?), pero incluso en ese tipo de entornos de clientes ligeros, la gente todavía no actualizará el thin client (IE6 ¿alguien?)

Lo mejor que puede hacer es alentar a los clientes a actualizar, tal vez haciendo actualizaciones automáticas por defecto. Si sus clientes fe Si se necesita una gran cantidad de UAT, es posible que ya los hayas alterado al actualizar las cosas de las que dependen, y luego se corrigen tardando en aparecer. Si es así, mira cómo mejorar tus pruebas y el proceso de control de calidad.

No estoy seguro de que haya mucho más que pueda hacer para mejorar esto tristemente.

Answer 3

Lamentablemente, este es el tipo de cosas que debe haber decidido antes de firmar cualquier contrato con su primer cliente. Si no está en el contrato, no existe.

Para la envoltura retráctil, no debería importarle. No hay contrato, por lo que no tiene obligación de brindar ningún tipo de soporte. Independientemente del deseo de mantener buenas relaciones. El hecho es que ya ha obtenido su dinero del cliente anterior. Apoyarlos a perpetuidad reducirá las ganancias que ya reciben a nada en muy poco tiempo. Si realmente desea pasar a un modelo de servicio, no puede vender el software en envoltura. (Piense en el software antivirus. Deje de pagar, dejan de actualizarse)

Proporcione una lista de fechas en su sitio web para saber cuándo dejará de admitir versiones anteriores y atenerse a ellas. Si no les gusta, pueden buscar un nuevo software. Nunca se le garantizaron ventas futuras.

EDITAR, en respuesta al comentario: Entonces, como he dicho, su problema son sus contratos. Si no le dan la capacidad de decir "debe actualizar" o "no admitimos más que las últimas tres versiones menores", su empresa está equivocada. En el futuro, debe asegurarse de que sus contratos futuros incluyan dicho lenguaje. El soporte continuo solo significa lo que el contrato dice que significa.

Answer 4

tenemos versiones de mantenimiento y normales.

Supongamos que estamos trabajando en la versión 5.5 y el cliente encontró algunos problemas en la versión anterior que puede estar en 5.4.0.1, les proporcionaremos la solución en 5.4.1.0 y también haremos la modificación en nuestra versión actual, es decir, 5.5 In de esta manera tratamos de cerrar los números anteriores en la versión actual, así como proporcionar un nuevo kit para el cliente en la antigua versión

Answer 5

el siguiente flujo de trabajo podría ayudar a (pero tu caso es distinto):

1. Crear una rama de tema para corrección de errores, ramificándolo en el punto más temprano (e .gramo. Versión 1.0), nombrado p. 'foo-bugfix'
2. Crear nueva rama para la versión de mantenimiento para la versión, p. 1.0, si aún no existe, y si existe una falla en esta versión, llamada e., G. 'maint-1.0'
3. Fusiona la rama de la solución de errores en la rama de mantenimiento, resolviendo conflictos, en su caso.
4. Modifique el número de versión si es necesario. Etiquetar nueva versión de mantenimiento, p. '1.0.1'
5. Repetir 2-4 para otras versiones que desea apoyar

Por lo general, a pesar de que haces versión de mantenimiento (por ejemplo, en la rama llamada 'maint' o 'mantenimiento') sólo para la última versión del proyecto. Sin embargo, es una buena práctica, creo, si encuentra una falla grave (por ejemplo, una falla de seguridad grave) para solucionarlo en todas las versiones que se vean afectadas (tal vez limitándose a versiones que no son demasiado antiguas/todavía se usan ampliamente).

HTH

Answer 6

Lo que sugeriría es preguntar siempre que el cliente lo menos intentar la última revisión: pasar de 1.0 a 1.1 a ver si se soluciona su problema. Primera pregunta hecha

Lo que ayuda aquí es asegurarse de no incluir nuevas características en los lanzamientos puntuales a menos que cubran un gran agujero funcional en el software. Realice lanzamientos puntuales que solo están destinados a corregir errores y, como máximo, eliminar un diseño funcional deficiente. Guarde nuevas funciones para canalizar a su cliente a una recompra de su producto :-)

No introducir nuevas funciones con versiones puntuales también puede reducir el temor de sus clientes a la introducción de nuevos errores; la razón por la cual son típicamente reservados cuando se trata de instalar nuevas versiones.

Si un cliente todavía tiene el problema con su versión de punto actual y es urgente que podría obtener una 'revisión'. Si la versión de punto actual es 1.2, la revisión puede incluirse en la versión preliminar de 1.3 que se proporciona al cliente. Este cliente con urgencia ahora lo está ayudando a probar su versión de punto inestable y también puede ayudarnos a proporcionar comentarios sobre algunos otros cambios en el lanzamiento de puntos. Hacer una única versión de arreglo pequeño que se fusiona nuevamente en el lanzamiento de punto pendiente una vez que su cliente lo ayudó a probarlo también es una opción.

Esto se compara con el método del paquete de servicio de Microsoft: Libere las revisiones a menudo y luego recógelas juntas en un paquete de servicio (-> versión de punto). Antes, las revisiones de lanzamiento general a menudo se prueban junto con los clientes que enfrentan problemas para solucionar el parche.

Lo que definitivamente desea evitar es tener un "1.0.1-cliente A" y "1.0.1-cliente B", está invitando a la complejidad y al infierno del mantenimiento.

Normalmente, siempre debe fusionar sus parches en su línea principal. Si su cliente está ayudando a crear parches para su última versión, abórdelo.

Answer 7

Sugiero leer Version Control for Multiple Agile Teams y especialmente la sección Release branches (lo que funciona para N teams también funciona para 1 equipo).

Por lo que he leído hasta ahora en las diversas respuestas y comentarios, puede encontrar algunos buenos consejos en el mismo.