¿Cómo trabajo simultáneamente en la versión 1.1 y la versión 2.0?

Question

Situación: no tenemos beta y la versión 1.0 se ha lanzado a varios sitios de clientes. El Equipo A ya está ocupado trabajando en la versión 1.1 que tendrá correcciones de errores incrementales y ajustes de usabilidad, mientras que otro equipo trabaja en la versión 2.0 con cambios a gran escala, donde el núcleo del producto puede haber sido completamente rediseñado. Ahora, la mayoría de los cambios realizados para 1.1 tendrán que llegar a 2.0 en algún momento, y algunas de las correcciones de errores realizadas en la rama 2.0 podrían, de hecho, necesitar ser programadas para una versión anterior. El problema es que, dado que 2.0 tiene diferencias fundamentales, no se pueden combinar los cambios de 1.1 sin conversión manual, ni viceversa.

Mi pregunta: ¿Cuáles son las mejores prácticas de control de revisiones para minimizar los conflictos de combinación y duplicar el trabajo en este tipo de situaciones? ¿Cómo puedo asegurarme de que mis equipos dediquen el menor tiempo y esfuerzo posible a los problemas de control de revisiones, al mismo tiempo que les proporciono parches regulares a los clientes?

Answer 1

Una buena manera es corregir cada error en la rama estable y fusionar la rama estable en la rama de desarrollo. Este es el patrón Parallel Maintenance/Development Lines, y la clave es fusionarse temprano y con frecuencia. La fusión con poca frecuencia y tarde significa que la rama de desarrollo es irreconocible en comparación con la estable, o el error no se puede repetir de la misma manera.

Subversion incluye el seguimiento de combinación desde la versión 1.5 por lo que se asegura de que el mismo conjunto de cambios no se fusione dos veces, lo que causa conflictos tontos. Existen otros sistemas (por ejemplo, Git, Mercurial, Accurev, Perforce) que le permiten realizar consultas del tipo "¿qué cambios en la rama A no se han fusionado en la rama B?" y seleccione las correcciones que necesita en la rama de desarrollo.

Answer 2

Probablemente dependa de un sistema de seguimiento de problemas para este fin, y me asegure de etiquetar cada cambio que haya que introducir en el código de línea externa. A continuación, puede asegurarse de que los comentarios de check-in para cada cambio hagan referencia al tema relevante, y sean claros al expresar la intención del cambio de código para que se pueda entender fácilmente cuando intente volver a implementar en el enlace troncal.

Answer 3

El artículo here (Día a día con Subversion) menciona que un método es actualizar constantemente la versión 2 con datos de la compilación de la versión 1.1. En el artículo, el chico dice que haga esto todos los días.

La parte que querrá leer se titula "¡Camarero, hay un error en mi baúl!". Está a la mitad del artículo.

Answer 4

Combine con anticipación, combine a menudo, y asegúrese de que el control de calidad en la línea principal conoce y revierte/verifica los defectos corregidos en cada parche de las versiones de mantenimiento.

Es muy fácil dejar que algo salga y "deshacer" un error en un lanzamiento posterior, y déjame decirte que a los clientes no les importa lo complicado que puede ser administrar múltiples sucursales: ese es tu trabajo.

Asegúrese de estar utilizando un sistema de control de fuente que admita ramificación y fusión (he tenido experiencia con Perforce y SVN, y aunque Perforce es mejor, SVN es gratuito).

También creo que tener una sola persona responsable de realizar las fusiones de manera constante ayuda a garantizar que sucedan regularmente. En general, soy yo o una de las personas mayores de nuestro equipo.

Answer 5

La forma en que manejamos esto en mi trabajo es mantener la rama principal como el código más avanzado (es decir, 2.0 en este caso). Crea una rama para el código 1.x y realiza todas las correcciones allí. Cualquier cambio en 1.x se debe fusionar (manualmente, si es necesario) en la rama troncal (2.0).

Insisto en que los desarrolladores de 1.x tomen nota del número de revisión para el compromiso 1.x y del número de revisión para la fusión 2.0 en el ticket para ese error. De esta forma, será más fácil darse cuenta si alguien olvida fusionar sus cambios, y el hecho de que tienen que seguirlo les ayudará a recordar.

Answer 6

bastante más de lo que dicen los demás, pero pensé que podría echar en mi experiencia con el manejo de desarrollo en múltiples ramas usando SVN

Con nuestro producto principal, tenemos la necesidad de desarrollar simultáneamente en las versiones en 2+ al mismo tiempo.

Originalmente utilicé el tronco principal como la versión de "desarrollo principal", con las etiquetas utilizadas para cada lanzamiento real. Las ramas se usaron para esfuerzos de desarrollo sustanciales para un nuevo conjunto de características. Luego, más tarde, cuando comenzamos a trabajar en 2, 3 y 4 lanzamientos a la vez, comencé a usar una rama para cada revisión.

Como mantengo el repositorio y también manejo empujando las compilaciones de QA, me aseguro de hacer "rollups" cada mañana, que consiste en combinar los cambios en el árbol comenzando con la rama más baja actualmente activa. Así que me acaban de fusionar los cambios de 1.1 a 1.2, que se fusionó con 1.3 con cualquier otro cambio de 1,2 ya que la última combinación, etc.

Cuando me comprometo, me aseguro de comentar siempre comprometerse con algo como

fusionaron 1.1 rev 5656-5690

puede ser un poco de dolor, pero funciona :)

Answer 7

un punto clave es capturado en this picture del médico de construcción: solamente fusionar una dirección .

Answer 8

Para responder a esa pregunta específica, muchos desarrolladores han cambiado de Subversion a Git. Pago y envío github.com.