Tutorial sobre branching (I)

9:55 0 Comments

A lo largo de 3 entregas veremos un pequeño tutorial sobre branching. En la primera entrega enunciaremos algunos conceptos y la necesidad de branching; en la segunda, cómo resuelve PlasticSCM el problema del branching, y en una tercera y última entrega veremos qué pasos hay que seguir en PlasticSCM para trabajar con ramas.

Introducción y necesidad de branching.

Cuando en el desarrollo de un proyecto software intervienen varias personas o se desea realizar un desarrollo iterativo de entrega incremental, en el cual se van publicando sucesivos releases del producto, se hace necesario un modelo de construcción estructurado, que se adapte a nuestra forma de trabajar y que facilite un desarrollo paralelo en la medida de lo posible.

Pero, ¿qué es realmente un desarrollo paralelo? Un desarrollo paralelo no es aquél en el que un programador espera a que otro acabe para editar un mismo fichero, sino aquél que permite que los programadores trabajen de forma independiente unos de otros, sin tener que preocuparse por si alguien estará trabajando sobre los mismos ficheros que yo.

Este modelo de trabajo es realmente productivo, pues permite aprovechar todo el potencial de cada desarrollador individual pero trabajando en colectivo. Claro, que no deja de ser una propuesta bastante ambiciosa. ¿Cómo lograr esto?

Planteemos otro problema: en un proyecto que utiliza desarrollo iterativo con entrega incremental, ¿cómo podemos organizar los sucesivos releases sin interferir unos con otros?

La solución a estos y otros problemas pasa por el branching, que consiste en crear distintas ramas de desarrollo, distintos flujos de progreso. Antes de entrar en materia, es conveniente aclarar que una rama es una herramienta, no una solución como tal, y como toda herramienta debe ser utilizada con responsabilidad y debe estar sustentada por una política de uso como base que permita aprovechar su potencial. Es decir: hay que decidir cuándo se crea una rama, cuándo se une tal rama a la rama principal, qué contiene la rama, etc.

También es necesario indicar que un mecanismo de branching tiene poca utilidad sin un mecanismo de merging (unión o reunión de distintas ramas) potente. Si no podemos unir las ramas secundarias a la rama principal de forma potente y a poder ser, sencilla y automatizada, de poco nos sirve poder ramificar.

¿Cómo resuelve el branching los anteriores problemas planteados? Para el primero, la solución pasa por crear una rama para cada tarea, o bien una rama para cada programador. De este modo cada programador trabajará en una rama independiente, en un espacio de trabajo independiente y no interferirá su trabajo con el de los demás, salvo en el momento de reunir los cambios con los del resto mediante una operación de merge. El segundo problema se puede resolver creando una rama para el release. Las pruebas y modificaciones que se realicen sobre ese release se realizarán sobre la rama secundaria creada a tal efecto, mientras que el desarrollo normal del proyecto puede continuar en la rama principal (posiblemente creando nuevas ramas por tarea o por programador), con lo cual el desarrollo no queda parado.

0 comentarios: