Subversion con integración continua

Question

Disculpa si las respuestas a esta pregunta ya existen, no las encontré todavía.

Soy miembro de un equipo de desarrollo web, mantenemos un portal web. Release Management funciona con Subversion. Así es como yo trabajo al añadir nuevas características al portal:

• Crear una nueva rama copiando el tronco
• se desarrollan en esa rama
• Periódicamente mezcla actualiza desde el tronco en esa rama (quiero saber si Marco-Cambios romper mi código, antes de que vaya a UAT/Integración, por ejemplo)
• reintegrar a la rama en el tronco con el fin de dejar que ir a vivir

Ahora tenemos un problema con continuo Integr ación:

• periódica de entrada en funcionamiento cada X semanas existen
• varias ramas que se prevé que la entrada en funcionamiento en diferentes fechas
• horas cada x al día, Integration Server hace una extracción del tronco y se fusiona todas las ramas (que debe ir de forma explícita al Sistema de Integración) en ella
• las actualizaciones del tronco que se han fusionado en cada rama (véase más arriba) ahora generan conflictos árbol

¿Cuál es la mejor práctica para tha t? Reintegrar no funciona para fusionar varias Sucursales, porque tan pronto como una Sucursal se integra, la copia de trabajo ya no está limpia. Sin embargo, la integración continua debe ser posible de alguna manera ...

Si los cambios de Trank se fusionan en cada rama, se crean diferentes revisiones. Pero los archivos deben tener el mismo contenido y ser iguales. ¿No existe una opción de fusión que diga "ignorar un conflicto si los dos archivos nuevos/modificados son idénticos"?

Gracias por cualquier ayuda.

Answer 1

lo que usted describe es no integración continua por lo siguiente requisito:

horas

cada x al día, Integration Server hace un check out Tronco y combina todas las ramas (que debe ir de forma explícita al Sistema de Integración) en ella

real Continuous integration incluye los pasos siguientes:

• Actualizando el código fuente desde una rama específica (trunk, por ejemplo).
• Creación de código fuente que produce un artefacto de construcción que podría ejecutarse o desplegarse. Algunas veces esta fase incluye también ejecutar pruebas unitarias e inspecciones.
• Muestra el estado de compilación, si fue exitoso o no: verde o rojo.

Si tiene varias ramas, significa que debe configurar varios planes de compilación para varias ramas con el fin de realizar una integración continua para cada rama por separado.

Por lo tanto, no podría haber una mejor práctica para lo que describió porque las fusiones siempre deben realizarse manualmente. Esto se debe a los conflictos de fusión. Ocurren con bastante frecuencia y se pueden resolver solo de forma manual. La integración continua no ayudará.

Si acaba de confundir con los términos y desea realizar lo que describió de todos modos, diría que su proceso de desarrollo es un poco defectuoso. Probablemente, no es necesario realizar la fusión de varias ramas al mismo tiempo. Todo el desarrollo que entregue con mayor frecuencia debe concentrarse en una rama. Muy a menudo, tal 'una' rama sería tronco.

En su caso, parece que el desarrollo valioso está disperso entre varias ramas. Eso no está bien. Una vez que decida que se debe incluir alguna funcionalidad en la próxima versión, se debe integrar en una sola rama (probablemente principal) y permanecer allí como parte de la base de código. Intenta reducir la cantidad de ramas que tienes.

En resumen,

1. Excluir merge all branches paso de su proceso (esto no se debe hacer de forma automática).
2. Haga la fusión manualmente en su lugar.
3. En caso de que necesite tener sucursales todo el tiempo, configure la integración continua para tales ramas por separado.
4. De lo contrario (no es necesario que conserve las sucursales todo el tiempo, y pueden reintegrarse fácilmente en la sucursal principal una vez que finalice el desarrollo) reduzca el número de ramas a un mínimo de.

¡Buena suerte!