Nuestro equipo acaba de pasar de FogBugz & Kiln / Mercurial a Jira & Stash / Git. Estamos utilizando el modelo Git Flow para ramificar, agregando ramas de subtareas fuera de las ramas de características (relacionadas con las subtareas de Jira de características de Jira). Estamos usando Stash para asignar un revisor cuando creamos una solicitud de extracción para fusionar nuevamente en la rama principal (generalmente se desarrolla pero para las subtareas nuevamente en la rama característica).
El problema que estamos encontrando es que, incluso con la mejor planificación y desglose de casos de características, cuando varios desarrolladores trabajan juntos en la misma característica, digamos en el front-end y el back-end, si están trabajando en un código interdependiente que sea en ramas separadas, un desarrollador termina bloqueando al otro.
Hemos intentado tirar de las ramas de los demás a medida que nos desarrollamos. También hemos intentado crear ramas de integración local que cada desarrollador puede extraer de varias ramas para probar la integración a medida que se desarrollan. Finalmente, y esto parece funcionar posiblemente lo mejor para nosotros hasta ahora, aunque con un poco más de sobrecarga, hemos intentado crear una rama de integración fuera de la rama de características desde el principio. Cuando una rama de subtareas (fuera de la rama de características) está lista para una solicitud de extracción y revisión de código, también combinamos manualmente esos conjuntos de cambios en esta rama de integración de características. Entonces, todos los desarrolladores interesados pueden pasar de esa rama de integración a otras ramas de subtareas dependientes. Esto evita que alguien espere a que una sucursal de la que dependen para pasar la revisión del código.
Sé que esto no es necesariamente un problema de Git: tiene que ver con trabajar en código interdependiente en varias ramas, mezclado con nuestro propio proceso de trabajo y cultura. Si no tuviéramos la estricta política de revisión de código para el desarrollo (rama de integración verdadera), entonces el desarrollador 1 podría fusionarse para desarrollar para que el desarrollador 2 pueda extraer. Otra complicación es que también estamos obligados a hacer algunas pruebas preliminares como parte del proceso de revisión del código antes de pasar la función a QA. Esto significa que incluso si el desarrollador front-end 1 se está retirando directamente de la rama del desarrollador back-end 2, ya que vaya, si el desarrollador back-end 2 finaliza y su solicitud de extracción está en revisión de código durante una semana, entonces el desarrollador front-end 2 técnicamente no puede crear su solicitud de extracción / revisión de código porque su revisor de código no puede prueba porque el desarrollador de back-end 2 '
La conclusión es que nos estamos encontrando en un enfoque mucho más serial en lugar de paralelo en este caso, dependiendo de la ruta que tomemos, y nos gustaría encontrar un proceso para evitarlo.
Lo último que mencionaré es que nos damos cuenta de que al compartir código entre sucursales que aún no han sido revisados y finalizados, en esencia estamos usando el código beta de otros. Hasta cierto punto, no creo que podamos evitar eso y estamos dispuestos a aceptarlo hasta cierto punto.
Respuestas:
El problema también podría radicar en una separación de tareas demasiado rígida entre el desarrollo de back-end y front-end.
Si un desarrollador front-end necesita una nueva API, ¿no es posible permitirle crear una API ficticia en el back-end (devolviendo siempre el mismo valor, por ejemplo) para validar el diseño? Luego, confirme esa implementación parcial con un código auxiliar y, por segunda vez, un desarrollador de back-end implementará la característica real.
Al romper la dependencia, obtendrá un mejor flujo y no tendrá que parar todo esperando una sola tarea que actúe como un cuello de botella.
fuente
Su problema: el desarrollador A se bifurca de Master, el desarrollador B se bifurca de Master, ambos trabajan en características estrechamente relacionadas, y el hecho inevitable de que las fusiones en la rama Master son difíciles debido a conflictos inevitables es lo que frena a todos.
Si esto es previsible, entonces A y B podrían crear primero una rama común, luego cada rama para su trabajo separado de esta rama común, fusionar cada uno de sus trabajos separados en la rama común, y ahora tiene una rama libre de conflictos que es mucho Más fácil de integrar.
fuente
Si el desarrollador 1 funciona en la función A y el desarrollador 2 terminó de trabajar en la función B que depende de la función A, entonces no hay forma de evitarlo: la fusión de la función B está en espera. No puede probarlo sin la función A, y no tiene sentido revisarlo todavía ya que un mayor progreso en la función A podría conducir a cambios en la función B.
Sin embargo, eso no significa que el desarrollador 2 esté en espera. El desarrollador 2 puede comenzar a trabajar en la función C y volver al ciclo de revisión-reparación de la función B una vez que la función A esté completa. Yo sé que el cambio de contexto no es óptimo, pero desde el momento en que va a tomar a función completa Una es probablemente mide en días no es que malo (que no está tirando de ellos hacia fuera "de la zona" de 15 minutos de lado la tarea)
fuente
Una cosa que puede hacer para ayudar a la situación es echar un vistazo a las formas de acortar el ciclo de desarrollo.
En el caso de que un desarrollador esté esperando una característica de otro desarrollador, ¿hay alguna forma de que una parte del primer trabajo de los desarrolladores pueda pasar por una revisión e integración antes de que toda la característica libere el bloque?
¿Hay formas de dividir las funciones en unidades de trabajo más pequeñas para mantener el ciclo de integración?
Además, ¿cuánto dura la integración? Si hay una vuelta larga en una compilación o integración, eso puede ralentizar toda la cola. Vea si hay algo que pueda hacer para acelerar el tiempo de construcción para que las colas se liberen más rápido.
fuente