Repositorios de Código, la Potencia de Trabajar con Ramas

Hablamos ya anteriormente de “Repositorios de Código Fuente”, una herramienta básica para ayudar a mantener la “Gestión de Configuración” de nuestro proyecto (algo de lo que hemos hablado también).
Entre las principales bondades de los Repositorios de Código hablamos de la trazabilidad completa y de la posibilidad de trabajar con ramas. El uso de ramas es algo en lo que me gustarí­a hacer algo más de fuerza, ya que me temo que aunque haya bastante gente que esté acostumbrada a trabajar con respositorios como CVS, Subversion y SourceSafe, no hay tanta que esté acostumbrada a utilizar la posibilidad de utilizar ramas, una opción que permiten los tres repositorios.
Pongo un ejemplo de una situación que seguramente os sonará.
Estamos desarrollando una aplicación de la cual hemos liberado nuestra flamante version 1.0, fruto de un esfuerzo de varios meses de trabajo. Una vez liberada, varios clientes adquieren la aplicación por la cual pagan una cantidad de dinero tanto por su adquisición como por el mantenimiento de la misma (nuevos módulos y corrección de errores). Pasan las semanas y tras las primeras impresiones que se reciben por parte de los clientes, se decide comenzar el desarrollo de nuevos módulos y ampliación de los módulos existentes. Y cuando llevamos ya un mes de nuevos desarrollos para lanzar la esperada versión 2.0… uno de nuestros clientes explota un error de aplicación debido a que un módulo en concreto gestiona de manera incorrecta la memoria. Este fatí­dico error provoca que el cliente no pueda facturar el mes, y deja al descubierto un problema que se puede dar también en el resto de clientes que están utilizando la v1.0.
¿Qué hacemos ahora? Estamos a mitad del desarrollo de la v2.0. Ante esta situación podrí­amos plantear una solución de mí­nimos que pasarí­a por invitar al cliente que ha detectado el error a esperar a que salga a la luz la v2.0, y mientras tanto rezar que el resto de clientes que tienen la v1.0 (ya hemos vendido e instalado la aplicación en más de 20 clientes) no les ocurra lo mismo.
La otra opción, claro está, es utilizar ramas. Si tras cerrar la v1.0 hemos marcado la versión como lí­nea de base, estamos salvados. íšnicamente tendremos que partir de la v1.0, hacer la rama correspondiente y actualizar el código necesario para resolver el error. Una vez realizados los cambios, marcamos dicha versión como la versión 1.0.1, paquetizamos, y enviamos la versión de actualización a todos los clientes. Además, el propio repositorio de código va a permitir que podamos solventar directamente los cambios de código en la futura v2.0, en la que debemos evitar también el error.
Esta segunda solución va a permitir entre otras cosas mantener dos equipos de trabajo, uno centrado en nuevos desarrollos y otro preparado para solventar los posibles errores o pérdidas de versiones ya publicadas. Además dicho segundo equipo serí­a el encargado también de mezclar las correcciones en la nueva versión.
Saludos.
Miguel.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.