svn - from - Subversion Branch/Trunk Best Practice-¿mantener actualizada la sucursal?
svn trunk (5)
Mi equipo de desarrollo ha trabajado con subversión durante bastante tiempo. La forma de administrar el tronco y las ramas es la siguiente:
Nosotros (casi) siempre salimos del maletero
Cada lanzamiento 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 próxima 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 ser fusionar los cambios en el tronco en la rama de publicación de forma periódica, por ejemplo, semanalmente, para garantizar que los cambios troncales más actualizados se encuentren en la rama. 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).
Asumiendo que tengo su modelo aquí: desarrolla cambios importantes en el proyecto en una rama (fuera del tronco) que puede volverse bastante vieja.
Continúa realizando otro desarrollo en trunk que siempre contiene el software "en vivo", por lo que estos cambios son actualizaciones menores y correcciones de errores. Tienes problemas cuando fusionas la rama de desarrollo monumental de nuevo en el maletero.
Solo puede administrar de manera efectiva 2 versiones simultáneas de productos con ese modelo, lo cual puede ser suficiente por ahora, pero de todos modos puede morderlo de otras formas y empeorará si alguna vez necesita administrar 3 o 4 versiones. ¿Puedo sugerir que inviertas tu forma de trabajar?
Tener una rama de Versión para cada lanzamiento. Esto debe ser ramificado desde el tronco (en cualquier revisión). La única forma de modificar la rama de la versión es combinar las revisiones desde el enlace troncal.
Esto significa que puede trabajar principalmente en trunk 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 forma, puede mantener todo lo que desea lanzar en la sucursal, pero solo publicar lo que le satisface, porque eso es todo lo que se fusiona con la rama de la versión.
Todavía puede tomar ramas de desarrollo si lo necesita, pero puede mantenerlas como objetivo y pequeñas, tal vez funciones individuales en lugar de proyectos grandes.
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 fusión de svn.
En primer lugar, estoy totalmente de acuerdo con los encuestados anteriores en que no existe una solución única para todos.
En nuestro caso, tenemos muchas aplicaciones relativamente pequeñas, y cada aplicación normalmente solo tiene un único 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;
- Usamos ramas para desarrollar nuevas características, correcciones de errores, etc. Las ramas se fusionan de nuevo al tronco cuando se completan;
- Para lanzar, creamos una etiqueta del tronco actual y lanzamos la etiqueta.
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.
En primer lugar, no creo que haya una solución única para todos cuando se trata de administrar las sucursales y lanzamientos de códigos. Pero para tocar algunos de tus puntos desde mi perspectiva:
Sí, fusionaría los cambios del tronco 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ñar proactivamente 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.
Quizás desee tener una rama de integración que no sea troncal. Esto se puede probar a diario y cualquier problema detectado aquí antes de que se vaya y rompa el tronco y asuste a todos.
Nuestra experiencia es diferenciar claramente:
- rama de desarrollo
- rama de consolidación (rama utilizada para consolidar el desarrollo, estamos seguros de que entraremos en producción)
Trunk es solo para la grabación de una versión estable, desde la que podemos ramificar.
En la "rama de desarrollo", podemos gestionar cambios importantes, incluidos algunos que no terminarán en la próxima versión (porque son demasiado complejos, no están listos en el tiempo, dependen de otros desarrollos tardíos, ...)
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.
Totalmente de acuerdo con Andy: no existe una solución única para todos, pero el problema no debería ser mantener su rama de publicación actualizada, sino al revés.
Un buen control de cambios evitará que su sucursal 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 por lo que dices que estás desarrollando en tu rama y luego se une de repente al tronco justo antes de soltarlo y solo cruza los dedos. Me pregunto cuántos errores estás presentando al hacer esto.