¿Cómo manejas el código de integración de múltiples ramas / desarrolladores cada sprint?

Acabo de recibir una llamada retro en la que los desarrolladores expresaron su preocupación por la integración de sus historias en la rama maestra en cada sprint. Todos los desarrolladores codifican dentro de su propia rama y hacia el final del sprint se fusionan en una sola rama maestra.

Luego, un desarrollador (generalmente el mismo) tiene la tarea de asegurarse de que todo se haya integrado bien con el código de otro desarrollador (la mayoría de los cambios están en la misma página. Por ejemplo, una historia de visualización de datos, una historia de filtrado de datos y un indicador de SLA).

¿Cómo podemos reducir esta carga y facilitar la fusión de nuestro código? Desde mi punto de vista, hacer que el PO o SM priorice las historias de una manera más eficiente para que no tengamos este tipo de dependencias en el mismo sprint puede resolver algunos de los problemas. ¿Cómo abordan esto los demás? ¿O es solo parte del proceso?

Si está utilizando Git, cada desarrollador se moverá de la developrama a su propia rama de características para asegurarse de que no se alejen demasiado de la línea de base actual. Pueden hacerlo a diario, de modo que las tareas que tardan más de un par de días permanecen sincronizadas y se combinan los problemas mientras se mantienen pequeños.

Cuando el desarrollador termina su trabajo, crea una solicitud de extracción . Cuando se aprueba, se fusiona con la developrama.

La developrama siempre debe tener un código de trabajo y estar lista para su lanzamiento en cualquier momento. Cuando usted haga realmente un comunicado, se fusionan developen mastery la etiqueta de la misma.

Si tiene un buen servidor de integración continua, 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 o desaprobar automáticamente una solicitud de extracción si la compilación falla o las pruebas automáticas 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 lo hicimos cada hora más o menos.

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

• Mantenga sus ramas de corta duración (parece que ya lo está haciendo).
• Deje que los resultados de su prueba 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 funcionan 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. Paquete de regresión estándar.

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

Estoy de acuerdo con una de las otras respuestas donde el autor declaró que Git PR resolvería este problema haciendo que cada desarrollador fusionara su propio trabajo.

Otro punto que creo es lo suficientemente importante como para dejarlo hasta el último párrafo. Le sugiero que ejecute pruebas manuales sobre sus compilaciones nocturnas, en lugar de esperar hasta el final del sprint. Los desarrolladores deben fusionarse tan pronto como la característica esté completa para que pueda integrarse, implementarse y probarse lo antes posible.

No

Dependiendo de su idioma y qué archivos está editando, puede que no tenga sentido que cada desarrollador los edite en su propia sucursal. Por ejemplo, en C # descubrí que lo mejor es que solo una persona edite los archivos de diseño de la interfaz de usuario a la vez. Estos son archivos autogenerados, por lo que el código a veces se mueve sin 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 complete el trabajo de la interfaz de usuario. Y / o, se crea una nueva historia para simplemente diseñar la interfaz de usuario, y las otras historias implementan la funcionalidad. O tal vez un desarrollador hace 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 (s), es posible que desee evitar trabajar en todas ellas al mismo tiempo. No los tire a todos en el mismo sprint, o no comience a trabajar en todos ellos hasta que uno o más hayan terminado.

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

Esto le permite fusionar sus cambios temprano en cualquiera de mastersus ramas de desarrollo conjunto sin romper nada. Otros desarrolladores pueden fusionar estos cambios nuevamente en sus ramas de características (o volver a crear sus ramas en consecuencia).

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

Las banderas de características tienen beneficios adicionales (por ejemplo, hacen que sea fácil hacer pruebas A / B). Consulte este artículo de Martin Fowler para obtener más información.

Estamos siguiendo un enfoque de rama de desarrollo separada para cada característica, y luego estamos fusionando las ramas con una rama de QA para probar en el entorno de pruebas de integración.

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

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

En pocas palabras, comprometerse y fusionarse a menudo reduce la ventana de oportunidad para los conflictos de fusión y reducirá en gran medida los conflictos. La otra parte está planeada por el líder, lo que puede garantizar aún más que el trabajo fluya sin problemas.

Las otras respuestas brindan una gran perspectiva sobre las mejores prácticas para los commits y, simplemente siguiendo estas, probablemente reducirá la gran mayoría de sus problemas de fusión. Es casi seguro que más fusiones sean necesarias, pero para un equipo más pequeño, su enfoque de sucursal por persona probablemente funcione lo suficientemente bien. Por supuesto, ¡no hace daño (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 líder que esté familiarizado con la base del código y pueda reconocer dependencias de diferentes tareas. Si no organizan el momento del trabajo y los compromisos, es probable que termine con conflictos de fusión y resolución línea por línea. Organizar las tareas \ sincronización 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 trasladar todas las tareas relacionadas al mismo ingeniero, para evitar el conflicto por completo.