lunes, abril 07, 2014

Como manejar ramas de desarrollo y no morir en el intento

En Subversion la respuesta es simple, estás muerto... A pesar de la literatura que pueda decir lo contrario, la práctica muestra que hacer merge de las distintas ramas en Subversion es un dolor de cabezas, y al final, en esa herramienta, la única forma de llegar a manejar las diferentes ramas es teniendo efectivamente diferentes ramas, es decir, generando un directorio clon del release correspondiente... al final, abuso del espacio y una forma poco elegante de resolver un problema que en teoría esta herramienta resuelve.

En Mercurial, a primera vista, la respuesta es simple... Mercurial fue diseñado con el merge en mente, por lo tanto, hasta cosas como gestionar cambios en archivos que han sido renombrados y otras proezas no es difícil... y en este caso, es cierto... aunque con un poco de letra chica.

En Mercurial hacer merge es simple, y manejar ramas, a primera vista resulta normal, pues de hecho si dos personas clonan un repositorio y comienzan a trabajar, implícitamente cada uno ha creado una rama diferente, que en su minuto deberá unificarse... y la clave del punto está en el "implícitamente", pues esto significa que ocurren cosas sin que el usuario tenga plena conciencia de lo que está ocurriendo, por lo mismo, tampoco tiene mucha claridad de que debe hacer, es factible, y ya me ha pasado en la vida real (esa en que los problemas nunca tienen como resultado un número bonito, como 2, 12 ó 34) en que al final, un desarrollador sigue en su rama, sin preocuparse de lo que le ocurre al resto, hasta que después de mucho, mucho, mucho avanzar (lease como hartos commits más tarde), viene el momento del merge, y los problemas aparecen.

Mercurial está pensado para hacer merges frecuentes, de hecho, aceptando las premisas de XP (Extreme Programming), la integración (merge) continua es lo deseable, pues encapsula el impacto de los cambios y facilita la detección del problema... y en este punto la realidad está de acuerdo con la literatura ;)
En ese sentido entonces, ¿cual es la mejor práctica para la gestión de ramas en Mercurial?

Breve paréntesis no tan breve ... Debo reconocer que he buscado en Internet (y he encontrado respuestas), y que he probado algunas, hasta formarme una opinión, y este post es justamente el resumen de mi opinión (y una descripción de las mejores prácticas que uno encuentra en internet).... o sea, un post del tipo "Yet Another Post About...", pero como la mayoría de la documentación que he encontrado está en inglés, digamos que es mi aporte para tener en español parte del conocimiento... fin del paréntesis.

En líneas generales, Mercurial permite los siguientes mecanismos de branching:

1) Implícito (no hay que hacer nada en especial, simplemente hacer commit en la rama default y luego sincronizar con un repositorio externo), en este modelo, lo relevante es hacer el correspondiente merge de una rama y la otra.

2) Con nombre, es decir, se crea explicitamente una nueva rama, en la cual se trabaja y se hacen los commits correspondientes, para luego hacer merge con la rama principal.

3) Utilizar la clonación del repositorio y trabajar en el repositorio clonado en forma independiente.

La 3era permite a su vez utilizar el branching implícito o con nombre... ahora, el punto relevante de este punto es como hacer el merge, pues un mal manejo de este tema lleva finalmente a un repositorio con la historia totalmente desordenada, difícil de entender.

La idea de los próximos posts son explicar cada uno de estos mecanismos (con sus ventajas y desventajas), y luego avanzar en la definición de las líneas relevantes de una estrategia de branching, que ayude a contar con una estructura ordenada.

No hay comentarios.: