¿Una mejor manera de manejar la bifurcación y la fusión?

Question

Operamos una tienda de desarrollo web con ~ 20 desarrolladores que trabajan en ~ 30 sitios diferentes en un momento dado y estamos dedicando una cantidad increíble de tiempo a administrar nuestros repositorios de subversión; tiene que haber una forma mejor.

Nuestros sitios de clientes generalmente tienen 3 entornos de implementación separados: desarrollo (troncal), puesta en escena (ramificación) y producción (ramificación).

Las nuevas características se revisan internamente en el desarrollo, luego se combinan con la etapa de revisión y aprobación del cliente, y finalmente se fusionan a la producción.

Nuestro flujo de trabajo actual: cada desarrollador que está trabajando en una nueva característica importante para un cliente creará una bifurcación desde el enlace troncal, trabajará en su función, actualizará regularmente desde el enlace troncal y luego fusionará los cambios nuevamente en el tronco (desarrollo) para revisión interna. Los desarrolladores que trabajan en pequeños cambios o correcciones, los harán directamente en el tronco.

Después del cierre de sesión interno, los cambios se combinan con la puesta en escena. Si es necesario realizar cambios, con mayor frecuencia se realizarán en el tronco y luego se fusionarán con la puesta en escena. Una vez aprobados, los cambios se fusionarán con la producción y luego se implementarán.

Las nuevas funciones no se revisan secuencialmente internamente o por los clientes, y todo se vuelve un poco complicado. Parece que estamos utilizando los procesos incorrectos, tiene que haber una forma mejor de hacerlo. Estamos muy interesados ​​en aprender a utilizar mejor el control de versiones, pero nos falta experiencia para comenzar el proceso.

¿Cuáles son las mejores prácticas para estos escenarios? Además de este foro, estamos interesados ​​en contratar un consultor experimentado que pueda ayudarnos a mejorar nuestros procesos.

¡Gracias!

Answer 1

Creo que branching by feature (o por equipo) sería mejor que la bifurcación por el desarrollador. La función se puede probar y obtener una vista previa antes de fusionarse a través de Desarrollo (Troncal) y en la rama de Etapa.

Mi equipo ha tenido una estructura similar de "Sucursal por calidad/medio ambiente" que pasé algunos meses investigando cómo convertir mejor para que los desarrolladores trabajen juntos y podamos reducir el impuesto de fusión. Me gustaría sugerir lo siguiente:

• Desarrollo (tronco/rama principal/raíz)
  • (FeatureName1 [versión]) - reemplaza rama para cada desarrollador.
  • Staging (si está manteniendo todas las emisiones en una sola rama)
  • Producción
  • (releasename) (MajorVersion) Staging - Mi preferencia para aislar diferentes versiones, incluso si se liberan al mismo entorno
  • (releasename) (versión) Producción

correcciones de estadificación se realizan directamente en la rama de estadificación (o rama niño de corta duración de estadificación si control de calidad y/o aislamiento mandato de riesgo), y luego se fusionaron fijar de nuevo a Desarrollo (tronco) como soo n como solución se acepta. PRECAUCIÓN: Preste mucha atención a las fusiones de Desarrollo mientras hay una solución provisional en curso.

Desde la perspectiva de control de calidad Prefiero que la versión final probada y la compilación sean los archivos binarios/archivos idénticos lanzados a la producción. El único cambio deben ser los archivos de configuración (con diferentes configuraciones configuradas en un repositorio). Esto significa que normalmente realizo la compilación final en "Puesta en escena" y la rama "Producción" o ReleaseVersion es un archivo de solo lectura que nadie crea. (Se puede usar una etiqueta o etiqueta en lugar de esta rama de custodia si dicha etiqueta es inmutable ... que no es el caso para TFS 2010 :-(.)

Consulte los diagramas interesantes en Visual Studio TFS Branching and Merging Guidance artículo de MSDN de febrero de 2011. para escalar esto ver Branching for Scrum y Parallel Feature Teams working on multiple releases in development. Monthly releases to production.. Ambos de estos vienen con algunos excelentes diagramas que se aplican a cualquier sistema de control de versiones.

también me sugieren mirar el TFS Branching Guide y el foro de discusión en este mismo lugar para una buena adicional patrones y orientación. (La metodología de ramificación es en gran medida independiente de las herramientas con excepción cuando se evitan las debilidades de las herramientas).

veo al menos un defecto fundamental en el proceso de ramificación originales:

Después de señal interna fuera, los cambios se fusionaron para puesta en escena. Si es necesario realizar cambios, con mayor frecuencia se realizarán en el tronco y luego se fusionarán con la puesta en escena.

Si un cambio de estadificación se hace en Desarrollo y luego se fusionaron para estadificación de nuevo entonces usted acaba de heredado todos los otros cambios realizados en la rama de desarrollo desde la última combinación de puesta en escena. O si selecciona el cambio (dejando todos los otros cambios para fusionarlos más tarde). Las herramientas de SCM están mejorando en el manejo de este escenario, pero las fusiones selectivas aún presentan riesgos significativos.

FYI: El patrón descrito originalmente es similar a "Branch By Quality" como lo describe Jeff Levinson. Puede funcionar, pero debe analizar cuidadosamente cómo gestionar la bifurcación de hotfix/qfe y fusionar los cambios de nuevo a Trunk.

Answer 2

En lugar de tener ramas separadas para la estadificación y la producción, es posible que desee considerar el siguiente enfoque:

Todos los desarrolladores siempre funciona fuera del tronco y cuando es el momento de ponerlo en la estadificación, se crea una etiqueta que indica una instantánea del código que va al entorno de ensayo.

Si su cliente lo aprueba, puede continuar y enviar la misma etiqueta a la producción.

Si no aprueban (digamos, encontraron un error), entonces simplemente sigue trabajando fuera de trunk y crea otra etiqueta con las correcciones de errores.

NOTA: dado que SVN no tiene el concepto obligatorio de una 'etiqueta', una 'etiqueta' es esencialmente una rama en la que aún puede codificarse. Sin embargo, no debe alterar (es decir, confirmar) la etiqueta que creó fuera de trunk.

Answer 3

Considerar cambiar a Git en lugar de Subversion. Git soporta este tipo de modelo de ramificación extremadamente bien y es muy liviano. Toma un poco de tiempo acostumbrarse, especialmente si te estás moviendo de Subversion, pero finalmente te compra mucho.

una sugerencia de flujo de trabajo de Git para una nueva característica podría ser:

1. Crear un tronco se ramifican.
2. Función de implementación, incluidas las iteraciones de revisión interna, en la rama de características.
3. Cuando el cliente cierra sesión en la nueva función, fusiona la rama en troncal y producción y (opcionalmente) elimina la rama.

Realmente no necesita tener una rama de etapas para este flujo de trabajo. Tampoco es necesario que mantenga las ramas de características una vez que se hayan fusionado: Git recordará el historial de cambios.

Este modelo es compatible con el desarrollo y revisión de funciones asíncronas/fuera de servicio bastante bien, ya que cada rama de características es esencialmente independiente.

Las sucursales son muy baratas en Git y la fusión suele ser bastante trivial.

Answer 4

No dice exactamente cómo se vuelve desordenado, pero supongo que es cuando todos fusionan su rama de características en el maletero. Yo sugeriría esto como un flujo de trabajo:

1. Todo el mundo trabajando para la próxima implementación funciona en el tronco y se compromete con regularidad; solo las funciones que toman más de un ciclo o que probablemente no se incluirán en la próxima entrega se deben trabajar en una sucursal separada. Llamamos a esas ramas de desarrollo y deben fusionarse al comienzo de un ciclo de desarrollo, no al final.

2. Cuando esté listo para la etapa, cree una rama de publicación. Continúe con la troncal como próxima versión, fusionándose en las ramas de desarrollo dirigidas a la siguiente versión. En este punto, las correcciones de errores pueden tener que fusionarse desde la rama de nuevo al tronco, pero solo se deben agregar correcciones de errores y no el desarrollo de características en la rama, por lo que no debería ser tan malo. En la práctica, para reducir la fusión innecesaria, normalmente no esperamos la creación de la rama de publicación hasta que realmente estemos listos para comenzar a trabajar en nuevas funciones.

3. Cuando llegue el momento de mover el código a producción, simplemente marque la rama de liberación y continúe usándola. Utilice esta rama para mantener esta versión del código con parches hasta que todos los sitios de sus clientes los reemplacen con la próxima versión.

Este modelo en el que se desarrollan en el tronco y cada versión se mantiene en una sola rama que funciona muy bien para nosotros en un ambiente donde a veces tenemos clientes que desean correcciones para las versiones muy antiguas de nuestro software.