Sucursales para Every Little Change?

Question

Tenemos un cliente (que tiene un cliente, que tiene un cliente) que nos está volviendo locos con las solicitudes de cambio a una base de código (en PHP). Nuestra primera respuesta fue simplemente trabajar en una troncal principal en SVN, pero el cliente a menudo vuelve y solicita que un determinado cambio deba enviarse a los servidores activos lo antes posible. Por otro lado, otros cambios se reducen en prioridad de repente, que originalmente se agruparon con otros cambios (aparentemente).

Estamos pensando en utilizar una sucursal para cada solicitud de cambio. ¿Está loco? ¿Qué otras soluciones podrían funcionar?

Gracias!

Editar: Esta es una pregunta realmente difícil para elegir la respuesta correcta. Gracias a todos por sus excelentes respuestas.

Editar: Sé que la mejor respuesta que elegí no era particularmente popular. Yo también quería encontrar una solución técnica a este problema. Pero ahora creo que si el cliente quiere un software con características que puedan implementarse de forma modular ... este problema debería resolverse en en nuestro uso del sistema de control de versiones. Tendría que estar diseñado en el software.

Editar: Ahora es casi un mes más tarde y mi compañero de trabajo/cliente me ha convencido de que múltiples ramas es el camino a seguir. Esto no solo se debe a la locura del cliente, sino también a nuestra necesidad de poder determinar si una función está "lista para funcionar" o "necesita más trabajo" o lo que sea. No tengo el SVN conmigo, pero nos fusionamos usando el consejo del Cookbook SVN: fusiona la rama de la revisión se ramificó a la revisión principal.

Además, al usar este sistema, fusionamos todas las ramas en algún punto y eso se convierte en el nuevo control de calidad y luego en la creación en vivo. Entonces nos ramificamos de eso.

Última edición (quizás): Meses después, este sistema aún funciona para nosotros. Creamos sucursales para cada boleto y rara vez tenemos problemas. Por otro lado, tratamos de mantener las cosas separadas en cuanto a lo que las personas están trabajando ...

Dos años después: Utilizamos GIT ahora, y ahora este sistema es realmente bastante razonable.

Answer 1

Una rama para cada solicitud de cambio suena como un exceso y tal vez algunos problemas más adelante.

intente agrupar las solicitudes de cambio en áreas lógicas para que pueda ver que un conjunto particular de cambios tiene un efecto lógicamente relacionado en la aplicación. Crea ramas para estos.

Creo que la verdadera respuesta a la pregunta es para arreglar el cliente. Debe dejar en claro a través de un contrato que estas solicitudes de cambio arbitrarias les costarán dinero y que podrían ralentizarlas. Si esto sigue así, su repositorio svn será el aspecto menos problemático del proyecto.

Answer 2

¿Qué tal crear una sucursal para la versión en vivo de su cliente, una sucursal para su nuevo desarrollo y una sucursal para sus cambios en curso?

Trabaja en la nueva sucursal de desarrollo cuando no estás siendo inundado con tareas.

Trabaja en la rama de cambios en curso cuando estás arreglando todas esas cosas divertidas que siguen volviendo loco. Cuando tengas una solución, combínala con la rama "en vivo" y con la rama "nuevo desarrollo".

De esta forma, la distribución de su cliente está en su propio mundo, su nuevo desarrollo continúa (y puede combinarse siempre que lo necesite) y su mantenimiento también se captura.

Trabajamos en una nueva rama de desarrollo, luego cada vez que decidimos hacer un parche, ramificamos el tronco y luego enviamos ese parche para Q/A. Si va y viene durante un tiempo, trabajamos en esa rama para corregir esos problemas y volver a unirnos al tronco cuando sea necesario para garantizar que todo esté sincronizado.Si algo regresó mucho después del hecho que debía abordarse en una versión anterior, siempre podemos repararlo en esa rama, y ​​nuevamente, simplemente fusionarlo en el tronco.

Answer 3

Sucursal por solicitud de cambio, con el aumento correspondiente en el costo para el cliente para la gestión adicional, es un buen enfoque para este problema.

Te costará más, en términos de tiempo, recursos disponibles para trabajar en otras funciones, etc., pero con muchos cambios no relacionados o características del proyecto que se estancan o cancelan, es probable que sea uno de los mejores enfoques.

Esto es realmente un sistema SCM independiente - pero Subversion ciertamente puede hacer lo que se necesita.

Answer 4

Quizás Subversion aquí no es la mejor herramienta para el trabajo. Aunque crear todas estas ramas es barato en SVN, volver a fusionarlas puede llevar mucho tiempo y ser muy doloroso.

Si echas un vistazo a GIT en lugar de SVN, encontrarás un sistema de control de versiones que es más poderoso para fusionarse en general. Agregado a eso, tiene la característica específica de "cherry picking". Es decir, las confirmaciones únicas pueden "elegirse" fácilmente de un árbol de desarrollo y agregarse a otra (la rama activa). Además, es fácil y conveniente en GIT fusionar varios commits en uno solo (incluso puedes agregar a un commit específico de otro árbol).

Por lo tanto, la creación de confianzas de una sola característica y su elección selectiva puede ser la solución para usted.

Answer 5

Sucursal por probado, trabajando cambio.
Etiqueta por versión.
Desarrollar en el maletero.
Repita.

:)

Answer 6

Al hacer muchos cambios rápidos en la rama "en vivo" de un proyecto, es necesario tener un proceso de revisión de código sólida para reducir la posibilidad de romperla. La revisión del código debe hacerse antes de hacer el check-in; y mantener alejado el desarrollo central de esa rama.

Una vez que se aprueba el cambio, puede registrar el cambio (y/o fusionarse en su rama de trabajo) y crear una nueva "etiqueta" una vez que se haya realizado.

Answer 7

En mi lugar de trabajo tenemos el siguiente sistema:

• rama estable: Aquí es donde probar y verificar el código estable va.
• Rama de mantenimiento: aquí es donde se realizan los errores de fijación en el establo. Cuando se verifica que las cosas funcionen, se fusiona en una rama estable.
• Ramas específicas del proyecto: cada subproyecto en nuestro producto tiene una rama. En un momento específico durante el año, todos los proyectos que se incluirán en la versión de este año se fusionan en la "rama de publicación". Esto es para que toda la fusión y esas cosas no se hagan una semana antes del lanzamiento.
• Sucursal de versión: Aquí es donde todo el desarrollo desordenado de la versión actual ocurre después de que los subproyectos se fusionaron. Combinado con estable después de la liberación está hecho.

Answer 8

Tenga una rama para cada LANZAMIENTO. Combine tantos cambios en un solo lanzamiento como tenga sentido: tener más ramas generalmente es bueno, puede combinarlos fácilmente en la mayoría de los casos, separarlos es un poco más complicado.

Tener una rama para cada versión significa que usted también tiene una rama para lo que está actualmente en producción (o lo que ACERCA de ser lanzado cuando las versiones están pendientes después de la fusión pero antes de la implementación real).

Eso es lo que hacemos de todos modos.

Answer 9

El escenario se explica por el abridor del hilo es un ejemplo del patrón de ramas de características: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

Son muy usefule cuando se tiene que mantener la línea de desarrollo principal (tronco) estable y hay que desarrollar una gran cantidad de características que potencialmente podrían romper la línea principal.

La desventaja es que debe mantener las distintas ramas sincronizadas con el tronco: mientras una rama para la característica A está en desarrollo, una rama para la característica B puede haber alcanzado un estado estable y cerrarse y fusionarse en el tronco : en esta situación, debe fusionar los cambios introducidos por la rama B del tronco a la rama A. Por lo tanto, es una buena costumbre fusionar a menudo las ramas con el tronco para evitar la situación problemática de una gran fusión única al final de la vida de la sucursal con muchos conflictos para rastrear y resolver.

Answer 10

Cuando las horas estimadas son más de 8, use una rama.

Answer 11

Con git, I do hacer una rama para cada pequeño cambio, y me encanta!