¿Está mi empresa fusionando sucursales mal?

Recientemente me encontré con un artículo de MSDN sobre ramificación y fusión y SCM: Ramching and Merging Primer - Chris Birmele .

En el artículo dicen que 'big bang merge' es una combinación antipatrón:

Big Bang Merge: diferir la fusión de sucursales hasta el final del esfuerzo de desarrollo e intentar fusionar todas las sucursales simultáneamente.

Me di cuenta de que esto es muy similar a lo que mi empresa está haciendo con todas las ramas de desarrollo que se producen.

Trabajo en una empresa muy pequeña con una persona que actúa como la revisión final + autoridad de fusión de troncales. Tenemos 5 desarrolladores (incluyéndome a mí), a cada uno de nosotros se le asignará una tarea / error / proyecto por separado y cada uno se bifurcará del tronco actual (subversión) y luego realizaremos el trabajo de desarrollo en nuestra rama, probaremos los resultados, escribiremos documentación si es necesario, realice una revisión por pares y un ciclo de retroalimentación con los otros desarrolladores, y luego envíe la sucursal para su revisión + fusión en nuestro software de gestión de proyectos.

Mi jefe, la única autoridad en el repositorio de troncales, en realidad diferirá todas las revisiones de sucursales hasta un solo punto en el tiempo donde realizará revisiones tanto como sea posible, algunas ramas serán devueltas para mejoras / correcciones, algunas las ramas se fusionarán directamente en el tronco, algunas ramas serán arrojadas hacia atrás debido a conflictos, etc.

No es raro que tengamos entre 10 y 20 sucursales activas en la cola de revisión final para fusionarlas en el tronco.

También con frecuencia tenemos que resolver conflictos en la revisión final y la etapa de fusión porque dos ramas se crearon desde el mismo tronco pero modificaron el mismo código. Por lo general, evitamos esto simplemente reorganizando el tronco y volviendo a aplicar nuestros cambios y resolviendo los conflictos y luego presentando la nueva rama para su revisión (rebase del hombre pobre).

Algunas preguntas directas que tengo son:

• ¿Estamos exhibiendo el anti-patrón que se describió como la 'fusión del Big Bang'?
• ¿Algunos de los problemas que estamos viendo son el resultado de este proceso de fusión?
• ¿Cómo podemos mejorar este proceso de fusión sin aumentar el cuello de botella en mi jefe?

Editar: dudo que mi jefe afloje su control sobre el repositorio de troncales, o permita que otros desarrolladores se fusionen con la troncal. No estoy seguro de cuáles son sus razones para eso, pero realmente no planeo mencionar el tema porque ha sido mencionado antes y derribado bastante rápido. Creo que simplemente no confían en nosotros, lo que no tiene sentido porque todo se rastrea de todos modos.

Cualquier otra idea de esta situación sería apreciada.

Algunas sugerencias:

• No hay nada de malo en tener muchas ramas de características o corrección de errores siempre que los cambios realizados en cada rama sean lo suficientemente pequeños como para que pueda manejar los conflictos de fusión resultantes de manera efectiva. Ese debería ser su criterio si su forma de trabajar está bien, no algún artículo de MSDN.

• Cada vez que una rama se fusiona en el tronco, el tronco debe fusionarse en todas las ramas de desarrollo abiertas lo antes posible. Esto permitiría a todas las personas del equipo resolver conflictos de fusión en paralelo en su propia rama y, por lo tanto, quitarle una carga al guardián de la troncal.

• Esto funcionaría mucho mejor si el guardián no esperara hasta que 10 sucursales estén "listas para fusionarse en el tronco" - resolver conflictos de fusión de las últimas integraciones de troncales siempre necesita algo de tiempo para el equipo, por lo que probablemente sea mejor trabajar en intervalos de tiempo entrelazados - una integración por parte del guardián, una nueva fusión por parte del equipo, la siguiente integración por parte del guardián, la próxima fusión por parte del equipo, etc.

• Para mantener las ramas pequeñas, podría ayudar dividir las características más grandes en varias tareas más pequeñas y desarrollar cada una de esas tareas en una rama propia. Si la función no está lista para producción hasta que se implementen todas las subtareas, escóndela de la producción detrás de una función de alternancia hasta que se completen todas las subtareas.

• Tarde o temprano, encontrará tareas de refactorización que afectan a muchos archivos en la base del código; estos tienen un alto riesgo de causar muchos conflictos de fusión con muchas ramas. Esos pueden manejarse mejor comunicándolos claramente en el equipo, y asegúrese de manejarlos exactamente como escribí anteriormente: integrándolos primero en todas las ramas de desarrollo antes de la reintegración, y dividiéndolos en sub-refactorizaciones más pequeñas.

• Para el tamaño de su equipo actual, tener un solo portero puede funcionar. Pero si su equipo crecerá en tamaño, no hay forma de tener un segundo guardián (o más). Tenga en cuenta que no estoy sugiriendo que todos se fusionen en el tronco, pero eso no significa que solo su jefe sea capaz de hacerlo. Probablemente haya uno o dos desarrolladores senior que también podrían ser candidatos para hacer el trabajo del portero. E incluso para el tamaño de su equipo actual, un segundo guardián podría facilitar que su equipo se integre al tronco más a menudo y antes, o cuando su jefe no esté disponible.

¿Estamos exhibiendo el anti-patrón que se describió como la 'fusión del Big Bang'?

Suena como eso

¿Algunos de los problemas que estamos viendo son el resultado de este proceso de fusión?

Seguro

¿Cómo podemos mejorar este proceso de fusión sin aumentar el cuello de botella en mi jefe?

En mi empresa, cada desarrollador tiene la capacidad de fusionarse. Asignamos una Solicitud de fusión a otro desarrollador, revisamos el ciclo de revisión / retroalimentación / actualización hasta que ambas partes estén satisfechas. Luego, el revisor fusiona el código.

10-20 sucursales en espera de fusionarse es una señal de que su proceso es defectuoso. Si tuviéramos tantos, todo el trabajo de desarrollo se detendría hasta que se despejara.

Esto es esencialmente cómo funcionan muchos proyectos de código abierto, incluido el kernel de Linux, que tiene muchas más ramas en vuelo que usted en un momento dado. La forma típica de evitar las fusiones de Big Bang en estos proyectos es crear otra rama (o varias ramas) para una integración continua. Esta es la rama que usa para asegurarse de que sus cambios funcionen junto con sus colegas, y se vuelve a colocar periódicamente en el tronco cuando el guardián se encarga de hacer revisiones.

Opcionalmente, puede usar esta rama para combinar varias de sus propias solicitudes de extracción en una gran solicitud coherente para que su jefe la revise. Linus Torvalds generalmente recibe solicitudes de extracción que se han integrado en dos o más niveles de profundidad, y puede tener un tamaño del orden de, por ejemplo, un nuevo controlador de sistema de archivos completo.

Estoy de acuerdo con ambos Doc Brown pero también veo otro antipatrón:

Mi jefe, la única autoridad en el repositorio de troncales , en realidad diferirá todas las revisiones de sucursales hasta un solo momento en el que realizará revisiones tanto como sea posible, algunas ramas serán devueltas para mejoras / correcciones, algunas las ramas se fusionarán directamente en el tronco, algunas ramas serán arrojadas hacia atrás debido a conflictos , etc.

En mi humilde hay algunos antipatrones de gestión:

1. Él / ella es el único punto de estrangulamiento que limita la velocidad del equipo. Su factor de bus es 1. La teoría de las restricciones dice que debe esforzarse en mejorar la parte más lenta de la cadena.
2. Su gerente está haciendo que su ciclo de comentarios sea más lento y está reduciendo la agilidad de su equipo. ¿Puedes liberar cada semana?
3. La complejidad de las fusiones crece exponencialmente con la cantidad de código. Es mejor hacer 10 fusiones con 100 líneas que 1 de 1000 líneas. Esa es solo una de las razones por las que deberías hacerlo lo antes posible
4. Si detecta una falla en el tronco, lo hará a tiempo. ¿Cuál de las varias ramas fue la problemática?
5. Las decisiones deben ser tomadas por aquellos que tienen más conocimiento sobre ellas. ¿Quién sabe más en este caso? Apuesto a que los desarrolladores que hicieron el código.
6. No puede corregir un error en la producción si su gerente está de vacaciones.
7. Estás rehaciendo el trabajo y lanzando ramas hacia atrás. Esto es una pérdida de tiempo. El tiempo que está esperando alcanzar la producción también es un desperdicio.

Recomendaciones

• Su gerente necesita delegar la responsabilidad al equipo. Debes demostrar que el equipo es maduro, profesional. Dejar en claro que pueden confiar en el equipo
• Implementar algún método de revisión. Puede ser que necesite la aprobación de otros dos miembros del equipo.
• Puede estar usando SVN lo está haciendo más difícil. Prueba Git y mira si te ayuda. Aún más. Si usa GitHub, puede usar el mecanismo de solicitud de extracción para que una fusión requiera ciertos votos.
• Lea y comparta información sobre prácticas ágiles, integración continua y DevOps.

Cuando realiza trabajos de características en ramas separadas, no puede realizar fácilmente ninguna prueba de integración hasta que una de las ramas se fusione con el tronco y se coloque en las otras ramas de características. En mi experiencia, este es el principal problema con el antipatrón Big Bang Merge. Idealmente, debería realizar un trabajo de características, probarlo en la rama de características, fusionarlo en el tronco y, en ese momento, habrá terminado con la característica. Si no se ha fusionado, debe volver a visitarlo cada vez que algo más se fusione en el tronco antes que él. El dolor de este antipatrón es que tiene muchos errores de tipo de integración que aparecen al final del ciclo de desarrollo.

Entonces tienes 20 sucursales. La rama 1 acaba de fusionarse. Luego, el desarrollador de la rama 2 tiene que fusionar la rama 1 en su rama para poder fusionarse en main sin conflicto, luego se fusiona. Luego, el desarrollador de la rama 3 tiene que fusionar la rama 1 y la rama 2 en su rama para poder fusionarse en main sin conflicto, luego se fusiona.

Ejercicio para el lector: escriba un programa que imprima mi publicación completa :-)

Esto es una locura. Pasará una increíble cantidad de tiempo fusionándose.

Dada la forma en que trabaja y que su jefe es un fanático del control responsable, la ramificación en sí misma parece ser el problema. En lugar de crear una rama para cada característica, haga que cada desarrollador confirme su característica en partes, directamente en el tronco. Esto pone la carga de la integración en el desarrollador en múltiples pasos más pequeños (ganar-ganar). Gate keeper puede seguir el ritmo de los cambios más pequeños durante un período más largo antes en el ciclo de desarrollo y seguir siendo el maestro revisor.

La ramificación en sí misma es algo que no desea hacer a menos que tenga una muy buena razón para hacerlo o no tenga otra opción. Eres lo suficientemente pequeño como para mantener las cosas sincronizadas más estrechamente, lo que será más fácil y seguro.