Ramas de funciones, ramas beta y funciones eliminadas

7

He estado pensando mucho en las mejores prácticas con respecto a la bifurcación en sistemas de control de versiones distribuidos como git an mercurial (los dos DVD's con los que tengo experiencia y uso a diario).

La forma en que lo he estado haciendo es ligeramente diferente en cada uno de estos, pero generalmente sigue estas pautas:

  • rama principal: concurrente con el código de producción
  • rama de desarrollo: concurrente con el código "beta"
  • ramas de características - para el desarrollo de características

El desarrollo se realiza en una rama de características (generalmente se crea a partir de la rama maestra, por lo que sabemos que estamos trabajando con una base de código estable), y cuando el dev se completa, revisa y prueba al desarrollador, se empuja / fusiona en la rama de desarrollo / beta, colocada en un servidor beta y probada.

Si todo va bien, la función se aprueba y podemos fusionarla en la rama maestra / estable, realizarla, realizar las pruebas finales y ponerla en producción.

Sin embargo, si no va bien, las cosas se descomponen. Si, por ejemplo, una característica se desecha o se retrasa indefinidamente, es probable que queramos eliminarla de la rama dev / beta. Sin embargo, dado que las fusiones de master / stable (revisiones, cambios de contenido, etc.), y otras características nuevas probablemente se han colocado en la rama dev, es difícil eliminar una sola función de esa rama.

Llego a la conclusión de que este flujo de trabajo se ha interrumpido, pero parece que debería funcionar. Entonces, específicamente:

  • ¿Es posible eliminar una característica particular de este tipo de rama?
  • ¿Esto es solo un flujo de trabajo roto?

Y más en general:

  • Dado el desarrollo a largo plazo de las características, y la necesidad de tener una sucursal concurrente con en vivo, ¿cuáles son las mejores prácticas involucradas en dvcs?
pregunta Ryan Kinal 01.05.2013 - 22:17

2 respuestas

5

Creo que el flujo de trabajo en su núcleo está bien y básicamente sigue las ideas presentadas aquí: Un Git exitoso modelo de bifurcación . Sin embargo, creo que la razón por la que se descompone es porque básicamente estás "fuera de combate" en el proceso de fusión y prueba:

  • Las ramas de características se deben basar en la rama de desarrollo en lugar de la rama estable / maestra. Las características a largo plazo se rebasan continuamente en la parte superior de la rama de desarrollo.
  • Las ramas de funciones solo se deben combinar en la rama de desarrollo cuando estén listas y aprobadas para la próxima versión (es decir, cuando se combinen, definitivamente pasará a la próxima versión).
  • Cuando se prepara una nueva versión, se hace una rama de lanzamiento fuera de la rama de desarrollo donde se realizan las pruebas finales antes de fusionarse en la rama estable / maestra para la producción.

Las cosas se vuelven un poco más complicadas cuando una característica depende de otra característica que aún no se ha fusionado con el desarrollo, pero como Doc Brown mencionó en su responder , creo que" característica alterna "es una buena idea aquí. Las características casi completadas se fusionan en el desarrollo, pero se deshabilitan para uso de producción. Las funciones dependientes se vuelven a basar en la parte superior del desarrollo y se combinan cuando están listas.

    
respondido por el Oskar N. 01.05.2013 - 23:48
4

Creo que eliminar una función ya integrada después de una combinación es difícil con la mayoría de los VCS (o DVCS), por lo que debes asegurarte de que esta situación ocurra lo menos posible. Algunas ideas:

  • Si tiene una función para la que está en juego la aprobación (por ejemplo, primero necesita una prueba de usabilidad antes de estar seguro de que está creando la cosa "correcta"), asegúrese de que sus evaluadores hagan esa usabilidad. prueba ya con una versión de la rama de características, antes integrándola en la rama de desarrollo. Así que puedes evitar la integración si la característica está en juego

  • Según mi experiencia, los segmentos de funciones pequeños tienen un menor riesgo de ser desechados o retrasados que los grandes, ya que uno puede hacerlos mucho más fáciles y más rápidos listos para la producción. Por lo tanto, trate de hacer que los segmentos de funciones sean lo más pequeños posible.

  • Si tiene una función más compleja, que consiste en una docena (o más) de porciones de función, y desea que el usuario final vea esa función compleja solo como todo o nada, introduzca feature alterna en su código, y use una rama de características para cada sector, no para toda la cosa. Esto no hace que sea más fácil "desmarcar" cualquier código de función después, pero si, por ejemplo, después de la integración de la mitad de los segmentos de funciones en la rama de desarrollo, alguien decide no completar todo para la próxima versión, puede deje los segmentos de entidades terminados en la rama dev, sin activar la función de alternar. Por lo tanto, sus usuarios no notarán que hay una característica a medio completar allí.

EDITAR: Si realmente necesita la opción de "desmantelar" una característica en un momento en el que partes de ella se integraron en la rama dev y se mezclaron con otros conjuntos de cambios, tiene la opción de usar una rama de características separada (o debo decir "rama de características") para esa tarea. Cambia y / o elimina las partes relevantes del código dentro de esa rama, el desarrollador lo prueba y luego integra nuevamente el conjunto de cambios en la rama dev.

EDIT2: lea esta publicación del blog de Martin Fowler para obtener más información acerca de los alternadores de funciones.

    
respondido por el Doc Brown 01.05.2013 - 23:16

Lea otras preguntas en las etiquetas