En el tiempo que llevamos trabajando en consultoría relacionada con TFS, y en particular con lo concerniente al Source Control, nos hemos encontrado con dos tipos de casos:

• Empresas que no aprovechan los beneficios aportados por el branching.
• Empresas que hacen abuso del branching, que también pierden esos mismos beneficios y terminan siendo devorados por el monstruo.

Los primeros no quieren ni hacer mención al branching por simple temor a lo desconocido, pero en cuanto vencen ese primer miedo y obtienen los primeros buenos resultados, se convierten automáticamente en los de la segunda clase, casi sin término medio.

Los segundos vuelven a convertirse en los primeros por abandono.

Con este post me propongo  hacer una introducción a las políticas de branches, para que ambos grupos puedan lograr el equilibrio.

Branching Guidance

En gran parte de los casos con los que me he cruzado, el caos viene de la mano de la falta de políticas de branches. Casi como la planificación previa de la arquitectura de cualquier aplicación, los branches necesitan ser diagramados y consensuados de antemano.

Desde hace varios años ya, está publicada en Codeplex lo que se conoce como “Branching Guidance” sobre la cual estoy basando este post. Hoy la guía se encuentra en su versión 2.0 a raíz del feedback recibido desde la comunidad y recientemente fue publicado el Release 2010, obviamente apuntando al lanzamiento de la nueva versión de la plataforma.

En esa guía hay una frase a modo de advertencia que me gustaría transcribir:

Cada branch que se crea tiene un costo, por lo tanto asegúrese de obtener algún valor de él.

Creo que esta frase resume perfectamente el concepto de equilibrio al que hacía referencia  anteriormente, y al punto al que deberían llegar las empresas que decidan apostar por una política de branches.

Apostando a una política de branches

El uso de branching requiere ordenamiento, y por tal motivo voy a enumerar algunos principios que se deberán tener en cuenta antes de meter mano:

• El encargado de ejecutar y mantener la política de branches que se defina, deberá tener un nivel medio-avanzado en el manejo de TFS. (“Cada branch tiene un costo …”).
• La política que se defina dependerá fuertemente de los tipos de Release (release de nueva versión, de service pack, de hot fix, etc.) requeridos por el proyecto en cuestión, de lo que se desprende:
  • Se pueden definir diferentes tipos de políticas para diferentes tipos de proyecto.
  • A menor cantidad de tipos de release, un plan de branching más simple.

Los planes de branching sugeridos en la guía tienen una característica “aditiva” lo que permite elegir en primera instancia un plan simple, y en caso de que aparezcan nuevos tipos de release (conocidos como release vehicles, ver Glosario) ir “complicando” el plan agregando nuevos branches.

Un plan equilibrado – El “Standard Branch Plan”

Imaginemos un escenario con las siguientes características:

• Se desarrolla un producto del cual el cliente siempre tiene la última versión.
• Se desarrollan permanentemente nuevas versiones con nuevos features (un release vehicle por aquí).
• Se entregan además actualizaciones (services packs, bug fixes, otro release vehicle por aca).
• Cada actualización liberada sobre una determinada versión contiene todas las actualizaciones anteriores.
• Los services packs se desarrollan paralelamente a los features de la nueva versión.

Dado este escenario, un plan de branches como el que muestro a continuación permitiría soportar las necesidades del proyecto a la vez que mantendría una cantidad de branches controlada, fuera de una situación de caos.

Qué propone este plan:

• Branch Development:
  • Sobre él se desarrollan los features de la próxima versión.
  • Existe un flujo continuo desde y hacia el branch Main (merges).
  • Merge hacia Main (RI) ante cada objetivo cumplido, por ejemplo el fin de una iteración.
  • Merge desde Main (FI) cada vez que Main genera un build exitoso.
• Branch Service Pack:
  • Se crea en el mismo instante que Release, determinando en ese momento la jerarquía Main –> Service Pack –> Release.
  • Los cambios “de servicio” se hacen sobre esta rama y luego se hace merge (RI) sólo hacia Main.
• Branch Release:
  • Es hijo de Service Pack.
  • La entrega al cliente se hace desde este branch, y una vez que se libera, el branch se marca como read-only.
  • Bug fixes graves, que se hagan sobre el branch Release, deben hacer merge hacia Main pero pasando por el branch Service Pack (Release –> Service Pack –> Main)
  • Una vez que se creó este branch, los cambios que no fueron aprobados para el Release en curso sólo deberían hacerse en Main.

Herramientas de TFS

Con el lanzamiento de TFS 2010, se agregaron nuevas ventajas que facilitarán la vida del desarrollador que se encuentre con la difícil tarea de hacer los merges al momento de incorporar cambios a los diferentes branches, entre los que tenemos:

Visualización gráfica de la jerarquía de branches …

y visualización gráfica de los merges a los diferentes branches (incluye línea de tiempo …)

Con esta última mejora, podremos saber si un determinado cambio fue incorporado a un branch que lo requiera (si no se hubiera hecho el merge, el branch se vería en color rojo), y además, podemos saber en qué fecha y con qué changeset fue realizado.

Conclusión

Lograr equilibrios no es sencillo, pero los beneficios pueden ser muchos.

Invertir tiempo en la planificación y el mantenimiento de una política de branches que cubra nuestras necesidades pero que a la vez no se descontrole puede no ser fácil, pero seguramente permitirá reducir llamados de nuestros clientes enviando saludos a nuestras hermanas, madres y abuelas porque la entrega de la última versión, con aquellos fantásticos nuevos features, revivió bugs que habían sido ya solucionados.

Glosario