¿Deberías molestarte con las ramas SVN si solo tienes una?

Si solo trabajamos con una rama en Subversion, ¿deberíamos molestarnos? ¿No podemos simplemente trabajar en el maletero para acelerar las cosas?

Así es como nos desarrollamos con Subversion:

Hay un baúl
Creamos una nueva rama de desarrollo.
Desarrollamos una nueva característica en esa rama
Cuando se realiza la función, se fusiona en el tronco, se elimina la rama y se crea una nueva rama de desarrollo desde el tronco.

Cuando queremos lanzar a producción, hacemos una etiqueta desde el tronco. Las correcciones de errores se realizan en una rama de esa etiqueta. Esta corrección de errores se fusiona en el tronco.

Es por eso que creamos una nueva rama de desarrollo después de que se realiza una función. De esta manera, la corrección de errores se incluye lo suficientemente pronto en nuestro nuevo código.

A continuación se muestra un diagrama que debe aclarar:

Nuestra estrategia de subversión

Ahora, existe la sensación de que esta no es la forma más eficiente de trabajar. Desarrollamos localmente antes de comprometernos, lo que lleva unos 5-10 minutos. Puede comprender que esto se experimenta como un tiempo de espera bastante largo.

La idea de una rama de desarrollo es que el enlace troncal siempre esté listo para su lanzamiento. Pero esto ya no es cierto en nuestra situación. A veces, una característica está casi lista, y algunos desarrolladores ya comenzarán a codificar la siguiente característica (de lo contrario, estarían esperando a que uno o dos desarrolladores terminen y se fusionen).

Luego, cuando finaliza la función 1, se fusiona en el tronco, pero con algunas confirmaciones de la función 2 incluidas.

Entonces, ¿deberíamos molestarnos con la rama de desarrollo, ya que solo tenemos una rama? He estado leyendo sobre el desarrollo basado en troncales y la ramificación por abstracción, pero la mayoría de los artículos que he encontrado se centran en la parte de ramificación por abstracción. Tengo la impresión de que hay grandes cambios que abarcarán varios lanzamientos. Esto no es un problema que estamos teniendo.

¿Qué piensas? ¿Podemos trabajar en el maletero? El peor de los casos es (creo) que tendríamos que hacer una etiqueta desde el tronco y seleccionar los commits que necesitamos, porque algunos commits / características aún no están listos para la producción.

svn branching tagging

— Peter
fuente

Creo que sería mejor si tuvieras más de una rama. Uno para cada característica. De esta manera, si alguna vez comienza a trabajar en una función grande que llevará un poco de tiempo, no retrasará las correcciones de errores y similares para las versiones ya lanzadas.

— Amy Anuszewski

Una rama para cada característica parece hacerla más complicada, mientras intentamos reducir la complejidad. Además, si hay una corrección de errores (es decir, para 1.0), se puede hacer en una rama hecha de la etiqueta. Luego podemos etiquetar esa rama (haciendo un 1.1), liberarla y fusionar la corrección de errores en el tronco. El desarrollo de la característica grande continuaría en el tronco.

— Peter

Respuestas:

En mi humilde opinión, trabajar directamente en el enlace troncal está bien si puede comprometerse en pequeños incrementos y tiene una integración continua en su lugar, por lo que puede asegurarse (en un grado razonable) de que sus compromisos no rompan la funcionalidad existente. Hacemos eso también en nuestro proyecto actual (de hecho, no he trabajado en ningún proyecto usando ramas específicas de la tarea por defecto).

Solo creamos una rama antes del lanzamiento, o si una característica tarda mucho en implementarse (es decir, abarca múltiples iteraciones / lanzamientos). El tamaño aproximado de una tarea casi siempre se puede estimar lo suficientemente bien como para saber de antemano si necesitamos una rama separada para ella. También sabemos cuánto tiempo queda antes del próximo lanzamiento (publicamos lanzamientos aproximadamente cada 2 meses), por lo que es fácil ver si una tarea se ajusta o no al tiempo disponible antes del próximo lanzamiento. En caso de duda, lo posponemos hasta que se crea la rama de lanzamiento, entonces está bien comenzar a trabajar en él en el tronco. Hasta ahora, necesitábamos crear una rama específica de la tarea solo una vez (en aproximadamente 3 años). Por supuesto, su proyecto puede ser diferente.

— Péter Török
fuente

Estoy con Peter Tenemos una rama para cada versión compatible, pero de lo contrario trabajamos en el tronco. También utilizamos la integración continua, pero tenga en cuenta que esto solo significa que se compilará y no que no ha roto la funcionalidad existente, incluso con las pruebas unitarias.

— Ian

@ Ian, por supuesto, ninguna prueba puede garantizar en la vida real que el código esté 100% libre de errores ... con recursos limitados, nuestro objetivo es un nivel razonable de seguridad (cuya definición es específica del dominio y del proyecto). Tenga en cuenta también que CI también puede ejecutar pruebas de integración, etc., no solo pruebas unitarias.

— Péter Török

Esto funciona hasta que falla. Si necesita implementar una solución antes de que la nueva característica esté lista ... O si una nueva versión de la característica no estaba tan lista para el horario estelar como creía que sería mucho más difícil respaldar ese cambio del código si no usa la ramificación.

— SoylentGray

@Chad, los parches de la última versión se realizan en la rama de versión correspondiente, sin interferencias del tronco. Y probamos nuevas funciones de manera bastante exhaustiva para saber cuándo están listas para el horario estelar. Por supuesto, tenemos relativamente pocas características importantes en nuestro proyecto. Y dado que es una aplicación web del lado del servidor, es bastante fácil incluso agregar un indicador de DB para activar / desactivar selectivamente las funciones. YMMV.

— Péter Török

LOL ok, entendí mal y pensé que solo tenías el tronco (con una excepción). También he usado este método, está bien para un grupo pequeño y frecuentes lanzamientos pequeños, no funcionó bien para nosotros haciendo lanzamientos grandes de forma regular (3-6 meses ) intevales.

— SoylentGray

Lo que está describiendo con su desarrollo de características es el desarrollo paralelo (desarrollo simultáneo dirigido a diferentes lanzamientos de productos) y requiere ramas para manejarlo correctamente. Puede tener una rama para cada versión o para cada característica si a menudo tiene que recomponer las características que harán una versión en particular.

La otra forma de hacer esto sería trabajar desde el tronco de forma predeterminada, pero crear una rama si espera que su tarea se extienda más allá de la próxima versión. Siempre etiquetas el lanzamiento, por supuesto.

El enfoque que adopte realmente depende de la cantidad de administración que pueda hacer por adelantado. Si la versión típica no tiene un desarrollo paralelo, entonces tomaría el segundo enfoque.

— Jeremy
fuente

Estoy de acuerdo y OP confirmó esto con: 'A veces, una característica está casi lista, y algunos desarrolladores ya comenzarán a codificar la próxima característica ...'

— Chris

Sí, pero nunca tenemos que recomponer. Las características se implementan cronológicamente y, por ejemplo, las características 1-4 tienen que estar en la próxima versión (por ejemplo, 1.0). El único momento en que esto podría ser problemático es cuando el desarrollo ha comenzado en la característica 5, que es para el lanzamiento posterior (2.0). Luego debemos asegurarnos de que estos cambios no se incluyan en la etiqueta / versión (1.0). Hacer una rama antes de la publicación podría solucionarlo.

— Peter