¿Cómo maneja la integración del código de múltiples sucursales / desarrolladores en cada sprint?

Si está utilizando Git, cada desarrollador sacará de la rama develop a su propia característica rama para asegurarse de que no se alejen demasiado de la línea base actual. Pueden hacerlo a diario, por lo que las tareas que llevan más de un par de días permanecen sincronizadas y los problemas de fusión se resuelven cuando aún son pequeños.

Cuando el desarrollador termina su trabajo, crean una solicitud de extracción . Una vez aprobado, se fusiona en la rama develop .

La rama develop siempre debe tener un código de trabajo y estar lista para su lanzamiento en cualquier momento. Cuando realmente haces un lanzamiento, fusionas develop en master y lo etiquetas.

Si tiene un buen Servidor de Integración Continua, entonces construirá cada rama cuando se registren los cambios, especialmente para las solicitudes de extracción. Algunos servidores de compilación se integran con su servidor Git para aprobar automáticamente o rechazar una solicitud de extracción si la compilación falla o las pruebas automatizadas fallan. Esta es otra forma de encontrar posibles errores de integración.

Trabajé en un equipo donde luchamos con el mismo problema. Descubrimos que cuanto menos tiempo teníamos antes de integrarnos, menos difícil se volvía. Sé que la mayoría de las personas que enseñan integración continua hablan de comprometerse cada pocos minutos, probablemente en realidad nos comprometemos aproximadamente cada hora.

También encontramos que simplemente construir no era suficiente. Necesitábamos un buen nivel de cobertura de prueba para asegurarnos de que no rompiéramos accidentalmente el código de los demás.

• Mantenga sus ramas de corta duración (parece que ya está haciendo esto).
• Deje que los resultados de sus exámenes hablen por sí mismos.
• No esperes al final del sprint.

Ni siquiera necesita suscribirse a TDD para este. Todo lo que necesita son algunas pruebas que prueben que las características de sus desarrolladores están funcionando correctamente. Estos podrían incluir Pruebas Unitarias y Pruebas de Integración, pero idealmente serán un par de pruebas automatizadas de extremo a extremo de las características críticas. Cosas de paquete de regresión estándar.

Luego, una vez que se haya completado la fusión, puede verificar el informe de la prueba de automatización y verificar que todo se haya integrado correctamente.

Estoy de acuerdo con una de las otras respuestas en las que el autor declaró que Git PR resolvería este problema al hacer que cada desarrollador fusione su propio trabajo.

Otro punto que creo que es lo suficientemente importante como para dejarlo hasta el último párrafo. Te sugiero que realices pruebas manuales en tus construcciones nocturnas, en lugar de esperar hasta el final del sprint. Los desarrolladores deben incorporarse tan pronto como la función esté completa para que pueda integrarse, implementarse y probarse lo antes posible.

Don't

Dependiendo de su idioma y de los archivos que esté editando, es posible que no tenga sentido que cada desarrollador los edite en su propia rama. Por ejemplo, en C # he encontrado que es mejor que solo una persona edite los archivos del diseñador de UI a la vez. Estos son archivos generados automáticamente, por lo que a veces el código se mueve sin ninguna razón aparente, y esto causa estragos en la mayoría de las herramientas de fusión.

Esto significa que algunas historias pueden bloquear otras historias hasta que se realice el trabajo de UI. Y / O, se crea una nueva historia para diseñar la interfaz de usuario, mientras que las otras historias implementan la funcionalidad. O tal vez un desarrollador haga todo el trabajo de la interfaz de usuario mientras que otros implementan la funcionalidad de esa interfaz de usuario.

En una nota relacionada, si sabe que varias historias tocarán el mismo archivo, es posible que desee evitar trabajar en ellas al mismo tiempo. No los coloques todos en el mismo sprint o no comiences a trabajar en ellos hasta que uno o más hayan terminado.

Otro posible enfoque para evitar fusiones tardías y grandes son indicadores de características : protege sus cambios con un indicador configurable (idealmente dinámicamente) que evita que se activen antes de lo previsto.

Esto le permite fusionar sus cambios tempranamente de nuevo en master o en su rama de desarrollo conjunto sin romper nada. Otros desarrolladores pueden luego fusionar estos cambios de nuevo en sus ramas de características (o cambiar el formato de sus sucursales en consecuencia).

Como las otras respuestas ya han señalado, esto debería combinarse con una solución de integración continua.

Los indicadores de función tienen beneficios adicionales (por ejemplo, facilitan las pruebas A / B). Consulte este artículo de Martin Fowler para obtener más información.

Estamos siguiendo un enfoque de rama de desarrollo independiente para cada función, y luego estamos fusionando las ramas con una rama de control de calidad para probar en el entorno de prueba de integración.

Una vez que se completan las pruebas de regresión e integración, movemos fácilmente las funciones que están listas para comenzar, a la rama de lanzamiento.

Si todo va bien, fusionamos la rama de lanzamiento con la rama maestra.

En pocas palabras, cometer y fusionar a menudo reduce la ventana de oportunidad para fusionar conflictos y reducirá enormemente los conflictos. La otra parte es, de hecho, la planificación por parte del líder, que puede asegurar aún más que el trabajo fluya sin problemas.

Las otras respuestas brindan una gran perspectiva con respecto a las mejores prácticas para realizar confirmaciones y al seguirlas, probablemente reducirá la gran mayoría de sus problemas de combinación. Más fusiones es casi ciertamente una necesidad, pero para un equipo más pequeño, su enfoque de rama por persona probablemente funcione lo suficientemente bien. Por supuesto, ¡no duele (mucho) entrar en prácticas más extensibles!

Sin embargo, nadie parece haber abordado una de sus preguntas más importantes: qué hacer cuando todos están tocando las mismas áreas de código. Aquí es donde es útil tener un cliente potencial que esté familiarizado con el código base y pueda reconocer las dependencias de diferentes tareas. Si no organizan el tiempo de trabajo y los compromisos, es probable que termine con conflictos de combinación y resolución línea por línea. Organizar las tareas \ cronometrar es mucho más difícil con un equipo más grande, pero con un equipo pequeño es posible identificar estas tareas conflictivas. El líder podría incluso transferir todas las tareas relacionadas al mismo ingeniero, para evitar el conflicto por completo.