¿Debo crear una nueva rama para cada nuevo error que se informa?

Question

Usamos un JIRA como nuestro sistema de tickets. Nuevos errores/boletos se envían a ese sistema. Una vez que se resuelve un error, creamos una nueva compilación y la probamos en nuestro servidor de desarrollo. Si todo está bien, lo llevamos al servidor en vivo. Ahora normalmente trabajo en el maletero sin ninguna ramificación para arreglar los errores. Esto es, por supuesto, un problema. Porque puede haber muchos errores en nuestro sistema, pero solo algunos se solucionan a la vez. Sin embargo, si los arreglo a todos en la cajuela en lugar de en una rama, entonces nos vemos obligados a probarlos aunque no hayamos tenido tiempo suficiente para probarlos todos. ¿Cómo se suelen corregir errores y sucursales, etc.? (No estoy seguro si lo expliqué muy bien).

Answer 1

Aquí está la estrategia que uso. Me desarrollo en el tronco principal. Cuando se lanza el software, lo ramifico (digamos v1.0). Cuando ingresen los errores, corríjalo en el tronco de la rama y luego vuelva a fusionar con el tronco principal. Aquí hay una buena sinopsis de las estrategias que están disponibles: http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html

Answer 2

No estoy seguro de si es la estrategia normal, pero todos trabajamos en el tronco y luego respaldamos las correcciones de errores en las ramas de liberación. Nuestro tronco principal siempre es "inestable" y cuando sentimos que tenemos un tronco en estado liberable, lo ramificamos en una rama de liberación. A partir de ese momento, los buyfixes se transportan nuevamente a la rama de lanzamiento y la nueva funcionalidad solo se agrega al enlace troncal. Significa que puede ejecutar su rama de lanzamiento a través de pruebas y concentrarse en probar las correcciones de errores.

Answer 3

No recomendaría la ramificación en cada error reportado. Como dijiste, es posible que no decidas arreglar cada error que se informa, lo que significaría que tendrías muchas ramas muertas para podar en algún momento.

Si su herramienta & lo admite, la ramificación de cada error que decida corregir (y la función que decida implementar) no es una mala idea. Le permite desarrollar y probar cada corrección de error/función cuando tiene el presupuesto y la programación para hacerlo, y fusionarlos de nuevo en el tronco cuando esté listo.

Answer 4

Un modo común de operaciones es que el software implementado vive en una rama separada que solo recibe correcciones de errores. Donde realmente desarrollas esas correcciones es casi irrelevante; para evitar interferencias con el desarrollo actual, tiene sentido desarrollar la corrección en la parte superior de la rama "en vivo", luego probar/comprometer/implementar en el sistema en vivo y luego fusionar la solución nuevamente en el enlace.

Answer 5

Dividimos nuestras sucursales en versiones/versiones de productos, de modo que cada versión tenga su propia sucursal. El lanzamiento de la rama se prueba, por lo que solo es necesario probar las correcciones aplicadas a esa rama.

Además, cada versión de producto tiene un desarrollador y una rama principal. Los desarrolladores pueden comprometerse libremente con la rama de desarrollo sin temor a interferir con la versión (solo otros desarrolladores)

Answer 6

Tenemos el mismo problema (o casi), y creo que todos los desarrolladores lo tienen. Lamentablemente, todavía no puedo darte una respuesta por experiencia, sino solo teórica.

En mi opinión, siempre que sea una corrección de errores, se debe implementar tan pronto como sea posible. Lo que voy a implementar es una estrategia de rama de características y una rama de versiones. Esto significa que tenemos que diferenciar las características de los errores. y lo que se implementa está ramificado por separado (o etiquetado, en nuestro caso)

Al hacer esto, aún puede trabajar en el trunk para los errores y desplegarlos en su servidor de prueba, y una vez que se prueba y se aprueba se ramifica a la rama de lanzamiento y desplegarlo. también puede fusionar las correcciones de errores en su rama de características, o tratar de fusionar la característica más adelante cuando planee implementarla en el servidor de prueba.

De todos modos, creo que lo más importante es ramificar el trabajo prolongado que evita que implemente correcciones de errores más pequeñas. Si bifurca demasiado, tendrá un problema de fusión. Si no se ramifica lo suficiente, tendrá un problema de flexibilidad de implementación.

Answer 7

A menos que esté utilizando un SCM distribuido (Mercurial, Git, ...) donde la bifurcación es básicamente libre, la ramificación en cada error suena como una cantidad de trabajo irrazonable.

La estrategia habitual con el repositorio central SCM es tomar nota de la revisión que se supone que arregla el error y probar contra una compilación hecha con una revisión posterior. A continuación, puede fusionar la revisión en cuestión en la rama de publicación.

Estamos utilizando mercurial, y la ramificación para corregir errores y luego fusionar los cambios de la espalda es bastante factible en un SCM distribuido

Answer 8

Depende de su sistema de control de versiones. Si está usando git, donde las sucursales son baratas y las fusiones son fáciles, entonces definitivamente crearía una nueva sucursal para cada arreglo. Esto le permite mantener las correcciones de errores independientes entre sí, lo que permite una mayor flexibilidad con respecto a lo que se fusiona en el maestro/troncal, y cuándo.

Por otro lado, si está utilizando Subversion, las sucursales son más caras (en términos de creación y cambio/actualización) y la fusión es más difícil. A menudo, la relación costo/beneficio de una nueva sucursal no es lo suficientemente alta (especialmente para pequeños errores) para que valga la pena.