Integración continua con el desarrollo de varias sucursales en Subversion

Question

En el proyecto en el que estoy trabajando, estamos utilizando SVN con la estrategia 'Stable Trunk'. Lo que eso significa es que para cada error que se encuentra, QA abre un bug ticket y lo asigna a un desarrollador. A continuación, un desarrollador corrige ese error y lo comprueba en una rama (fuera del tronco, vamos a llamar a esto el bug branch) y que la rama se sólo contienen correcciones para ese particular bug ticket

Cuando decidimos hacer un lanzamiento, para cada correcciones de errores que queremos liberar al cliente, un desarrollador combinará todas las correcciones de varios bug branch a trunk y continuará con el ciclo de QA normal.

El problema es que utilizamos trunk como el código base para nuestro trabajo de CI (Hudson, específicamente), y por lo tanto, para todas las confirmaciones a la bug branch, se perderá la acumulación diaria hasta que se fusionó a trunk cuando decidimos lanzar la nueva versión del software. Obviamente, eso frustra el propósito de tener IC.

¿Cuál es la manera correcta de solucionar este problema?

Answer 1

Como observa, uno El propósito de usar una sucursal es segregar las fluctuaciones de código específicas de la fijación de tickets y el desarrollo de características fuera del enlace troncal. Pero una vez que la característica o el boleto está completo, debe fusionarlo nuevamente. En Subversion, las ramas se utilizan mejor para rastrear conjuntos de características relacionadas (como las de una versión), no funciones individuales. De lo contrario, terminará rápidamente con un número inmanejable de ramas.

Además, ¿por qué demorar la integración? Mientras más espere entre lanzamientos, mayor será la probabilidad de que su cambio aislado entre en conflicto con otro cambio realizado desde entonces y/o produzca más inestabilidad en su sistema una vez que se haya fusionado de nuevo.

Mi estrategia preferida es hacer algo como esto:

[begin work on 0.4 branch] 
     | 
     | 
     v    
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable". 
     \  |   |  Contains all commits. 
    ver \ [merge from trunk]  Developers commit to trunk. 
<-- 0.3 \  v   v 
      +---(a)--------(c)-- <-- Branch is "stable". 
            Contains selected commits from trunk. 
            Know beforehand what's going onto branch. 

Ahora, una vez que esté listo para el lanzamiento:

[trunk] 
(*)---(*)---(*)----------------------------[development continues]---> 


[0.4 branch]      No further development on branch unless 
(*)---(*)---(*)---[0.4-release]  spot fixes are needed. Then re-tag (0.4.1) 
         ^  and re-release. 
          |   
          | 
         [make tag on branch; release from stable branch, 
         not unstable trunk] 

Sé que le preguntó sobre la mejor manera de coaccionar a su continua sistema de integración para hacer esto. Pero, respetuosamente, sugiero que, dado que se reconoce a Hudson como un sistema de IC relativamente capaz, el hecho de que tenga muchos problemas para incorporar su modelo de desarrollo es una señal posible de que no es un proceso que se preste bien a CI. en primer lugar.

Nuestra práctica habitual es tener dos compilaciones base por proyecto: una contra el tronco y una contra la rama de lanzamiento actual. De esta manera usted sabe que:

• Lo que se está actualizando se está integrado de forma correcta (trunk)
• Sea cual sea su objetivo liberación es, si deja de trabajar ahora todavía tendría una correcta y trabajando (no todas las funciones) construir.

Answer 2

En lugar de crear ramas para las correcciones de errores, ¿por qué no intenta crear ramas para la versión antes de corregir el error y luego aplica la solución al tronco?

De esta manera, si quiere darles a sus clientes la solución de error, les da la versión troncal. Si no quiere darles la corrección de errores, puede darles la versión de la sucursal antes de aplicar su corrección.

De esta manera, puede hacer que Hudson construya la línea troncal, y sus versiones nocturnas incluirán todas las correcciones de errores.

Answer 3

Haz una fusión nocturna con un "tronco inestable-malvado" que fusiona todas las ramas de error con el tronco gemelo malvado.

O configura construcciones nocturnas en cada bifurcación (que suena como muchas construcciones nocturnas).

En mi opinión, esto suena como una gran cantidad de ramificaciones para una solución de control de fuente de estilo centralizado. Tal vez necesite un sistema de control de versiones distribuidas y un servidor de compilación en cada estación de trabajo, que parece lograr lo mismo (comprobaciones aisladas para cada desarrollador y compilaciones diarias de lo que los desarrolladores controlan)

Answer 4

Suena doloroso y demasiado complicado (desde el punto de vista de bifurcación/fusión).

Yo ramificaba en el lanzamiento y los desarrolladores se registran en el maletero. Todo lo que necesite salir como una solución urgente podría fusionarse con la rama de publicación.

Answer 5

de responder a esta mucho, y así es como IBM recomienda con ClearCase (UCM), y lo hago en el mundo real:

- Project 
    |- development mainline 
    |- TAG: version-1.0 
     |- version-1.0-bugfix#123 
     |- version-1.0-bugfixes 
    |- TAG: version-1.0-sp1 
     |- version-1.0-sp1-bugfix#234 
     |- version-1.0.sp1-bugfixes 
    |- TAG: version-1.0-sp2 

Todo lo que no prefijado por TAG es una rama.

Answer 6

Esto es lo que hacemos (inspirado en Version Control for Multiple Agile Teams por Henrik Kniberg):

• desarrollo se realiza en una rama de desarrollo y las características empujados al maletero cuando "hecho, hecho"
• tronco es el "hecho "rama
• ante un nuevo lanzamiento, marcamos el tronco
• cuando un defecto aparece, creamos una rama de lanzamiento de la etiqueta
• defectos está parcheado en la rama de lanzamiento
• parche se fusionó de rama liberación al tronco inmediatamente después de la liberación (incluirlo en futuras versiones)

CI se ejecuta en todas las ramas (ramas de desarrollo, tronco, ramas de liberación).