Subversion Branch/Trunk Best Practice: ¿mantener actualizada la sucursal?

Question

Mi equipo de desarrollo ha trabajado con subversion por bastante tiempo. La forma en que manejan el tronco y las ramas es la siguiente:

• Nosotros (casi) siempre se suelte del tronco

• Cada versión tiene su propia rama.

• Cuando un lanzamiento está listo para QA, fusionamos la rama nuevamente en el tronco y creamos una nueva rama para la siguiente versión.

• Los desarrolladores trabajan desde el tronco o la rama, pero no hay ramas específicas del desarrollador.

Últimamente, hemos tenido algunas sesiones de fusión de pesadilla, en parte debido a algunos cambios importantes en la aplicación. Estos no siempre se ejecutan sin problemas y los problemas a veces aparecen durante el control de calidad, donde la subversión no se fusionó del todo bien.

Una solución podría consistir en fusionar los cambios en el tronco en la rama de publicación de forma periódica, por ejemplo, semanalmente, para garantizar que los cambios más recientes en el tronco estén en la bifurcación. Los conflictos pueden ser arreglados más cerca de tiempo real.

¿Cuál es su experiencia con este problema? ¿Hay una mejor práctica estándar? Además, ¿tiene una buena manera de mantener un registro de las revisiones que se han fusionado en la sucursal (los comentarios decentes en subversión probablemente podrían manejar eso).

Answer 1

En primer lugar, no creo que haya una solución única para todos cuando se trata de administrar las versiones y los lanzamientos de códigos. Pero para tocar en algunos de sus puntos desde mi perspectiva:

• Sí, me gustaría fusionar los cambios de trompa en la rama de lanzamiento más a menudo. Los trozos más pequeños siempre serán más manejables que una gran integración. Y, por supuesto, esto significa que estás trabajando contra el último código más estable.

• Enseñe de forma proactiva a las personas cómo fusionarse bien. El desarrollador que hizo el cambio debería estar haciendo (o estar muy involucrado con) la fusión. Comprenda qué es lo que está tomando y cómo debería verse cuando esté terminado. A menudo veo que las personas ejecutan una integración sin saber realmente lo que están haciendo y lo que están esperando como resultado.

• Tal vez usted quiere tener una rama de integración, que no maletero. Esto se puede probar a diario y cualquier problema detectado aquí antes de que se vaya y rompa el tronco y asuste a todos.

Answer 2

Nuestra experiencia es diferenciar claramente:

• rama de desarrollo
• rama consolidación (rama utilizado para consolidar el desarrollo estamos seguros de que entre en producción

tronco es solamente para la grabación de la versión publicada estable, desde la cual podemos derivar.

En la "rama de desarrollo", podemos gestionar los cambios importantes, incluidos algunos que no va a terminar en la próxima versión (porque demasiado complejo, no está listo en el tiempo, depende de otros desarrollos finales, ...)

La rama de consolidación representa los pasos finales (tenga en cuenta el plural) necesarios para finalizar la publicación. Sucede después de una reunión en la que se validan todas las funciones necesarias para entregar.

Solo nos fusionamos en la "rama de consolidación" que estamos seguros pondrá en producción. Continuamos en esa rama hasta el lanzamiento final.

Answer 3

totalmente de acuerdo con Andy: No hay "una sola solución para todos", pero el problema no debe mantener su rama de lanzamiento hasta la fecha, más bien al revés.

El buen control de cambios debe evitar que su rama sea volátil. Los problemas de activación deben corregirse en la rama de publicación y luego fusionarse al enlace inmediatamente. Esté preparado para que esta "fusión" sea no trivial, el problema de la liberación de compuertas puede que ni siquiera exista en el tronco, pero debe hacer un análisis y probarlo.

Suena de lo que usted dice que está desarrollando en su rama, y ​​luego la fusión de todos a la vez a su tronco justo antes de soltar y cruzando los dedos. Me pregunto cuántos errores estás presentando al hacer esto.

Answer 4

En primer lugar, estoy totalmente de acuerdo con los respondedores anteriores que no hay una sola solución para todos.

En nuestro caso, tenemos muchas aplicaciones relativamente pequeñas, con cada aplicación que normalmente tiene un solo desarrollador. Cuando participamos en el desarrollo colaborativo, tiende a haber solo de 2 a 4 desarrolladores.

Nuestra política general es:

• El tronco contiene el estado actual del proyecto;
• Utilizamos las sucursales para desarrollar nuevas funciones, correcciones de errores, etc. Las sucursales se fusionan de nuevo al tronco cuando se completan;
• Para liberar, creamos una etiqueta del tronco actual y la lanzamos.

Andy también hizo un punto importante que debe enfatizar: "Enseñar proactivamente a las personas cómo fusionarse bien". Muchos, si no la mayoría de nuestros problemas, parecen surgir de malas prácticas de fusión.

Answer 5

Así que asumiendo Tengo su modelo aquí: Presenta cambios importantes en el proyecto en una rama (fuera del tronco) que puede llegar a ser muy antigua.

usted continúa haciendo otro desarrollo en el tronco que siempre mantiene el software 'en vivo', por lo que estos cambios son cambios menores y correcciones de errores. Tiene problemas al fusionar la rama de desarrollo monumental con el tronco.

Solo puede administrar de manera efectiva 2 versiones concurrentes de productos con ese modelo, lo cual puede ser suficiente por ahora, pero podría morderlo de otras formas y empeorará si alguna vez necesita administrar 3 o 4 versiones. ¿Puedo sugerir que inviertas tu forma de trabajar?

Tiene una rama de versión para cada versión. Esto debe ser ramificado desde el tronco (en cualquier revisión). La única forma de modificar la rama de versión es combinar las revisiones desde el enlace troncal.

Esto significa que puede trabajar principalmente en el tronco en lugar de en una rama de desarrollo grande. También aplica las correcciones de errores directamente al enlace troncal, por lo que no habrá problemas importantes de integración almacenados para el próximo lanzamiento. Para liberar correcciones de errores a las versiones anteriores, simplemente fusione las revisiones de troncales requeridas en la rama correspondiente de la Versión.

De esta manera puede mantener todo lo que desea lanzar en la sucursal, pero solo realmente libera lo que le agrada, porque eso es todo lo que se fusiona con la rama de la versión.

Aún puede tomar ramas de desarrollo si lo necesita, pero puede mantenerlas segmentadas y pequeñas, quizás funciones individuales en lugar de grandes proyectos.

Esto le permitirá administrar múltiples versiones de una manera sensata y mantener un buen registro de lo que hay en cada versión utilizando la información de combinación de svn.