Una de las cosas que más me sorprenden y escandalizan es la cantidad de empresas y compañeros que trabajan sin un repositorio de código. No conocen las virtudes de configurar un punto único en donde almacenar, versionar y recuperar las cientos o miles de horas/hombre invertidas en millones de líneas de programación.
Cuando toca juntar las fuentes de dos o tres personas es un auténtico dolor, pero la cosa se hace imposible cuando lo ha de realizar todo un equipo o departamento. Haciéndose una costumbre el perder código, o tener una árbol de carpetas de “copias de seguridad“ en el ordenador que se utiliza para hacer las publicaciones y que, generalmente, es el del líder del equipo.
Pero incluso cuando se establece, por fin, un repositorio de código, se trabaja continuadamente en un mismo tronco (trunk). El cual soporta las modificaciones y actualizaciones más variopintas. Sufriendo roturas a causa de errores o el no poder publicar hasta que se termine la decimonovena modificación o arreglo.
A estos equipos les invito a dar un paso en la escalera de la madurez del ecosistema y a leer esta serie que trata sobre la técnica de branching. Es decir, la forma de construir software alrededor de un núcleo estable, minimizando las causas de ruptura o de no disponibilidad.
Y que voy a iniciar con el etiquetado de las versiones.
Las herramientas
En el núcleo tengo el repositorio de código, control de versiones y gestor de proyectos: el Team Foundation Service Preview. Que es una versión en la nube del Team Foundation Server 11; a la que me han dado acceso por invitación. De precios y costes aún no se ha anunciado nada, pero es un servicio muy completo que me permite hacer prácticamente todo lo que puedo hacer con un TFS 11 beta pero con la flexibilidad, escalabilidad, accesibilidad y disponibilidad que nos provee un sistema basado en la Cloud. Un ejemplo más del desarrollo del concepto SaaS.
Para el que tenga máquina o que quiera trastear en un entorno local, puede utilizar el Team Foundation Server 11 Beta, que está disponible para su descarga y uso sin coste, hasta que salga la versión definitiva de pago. Y aún entonces, se va a publicar una versión gratuita.
El acceso al repositorio de código lo hago desde Visual Studio 11 beta, el cual ha remozado totalmente el interfaz de la antigua versión. Y que llevo utilizando desde la versión Developer Preview presentada en el evento BUILD del año pasado.
Pero tanto ahora como en el futuro puedo utilizar cualquier fabricante o versión de repositorio de código para poner en práctica el branching. Por ejemplo, un Visual Studio 2010 contra un SVN; o un Eclipse contra un TFS, o un Git; o incluso un muy poco aconsejable y anticuado sourcesafe.
Etiquetas, un primer paso
Una vez que he conseguido instalar el repositorio; y el equipo supere las primeras suspicacias y pérdidas de código por un uso inesperadamente sorprendente de los check-in, los check-out y las malas prácticas de copy, paste & move de ficheros físicos; llega el momento en que se hace parte de la cultura corporativa tener todo el trabajo en un solo sitio compartido, seguro y que se realice el versionado de forma automática y sencilla.
¿Pero qué pasa cuando hemos realizado una publicación en integración; y encontramos varios errores que hay que solucionar; y a los dos días nos damos cuenta que hemos roto la versión publicada y que hay que volver a la última válida? Pues que tenemos un desastre a la vista, ya que en esos dos días algunos ficheros han sido modificados, otros han sido borrados y la mayoría no se han tocado. Y, además, el impacto de cada uno de ellos en el resto de la aplicación depende de muchos otros factores.
La forma más sencilla de poder acceder a una versión específica de mi código, es por medio del uso de etiquetas. Es decir, hago una instantánea de la evolución de mi aplicación en un momento dado y le doy un nombre para poder recuperarla como una unidad. Así no tengo que preocuparme de saber qué versión de cada fichero es la correcta para el momento específico, ni cual ha sido cambiada anterior o posteriormente. Es una especie de backup de los hitos importantes en el desarrollo de la aplicación.
En TFS, realizar etiquetados es algo tan sencillo como entrar en la pestaña del Team Explorer, y seleccionar el enlace del Source Control Explorer para abrir la ventana del Explorador de Código. Aquí pulso el botón derecho del ratón encima del nodo raíz del proyecto, o el nodo que queramos etiquetar, y selecciono “Apply label“. Así abrimos una ventana emergente en donde debemos introducir el título de la etiqueta y su descripción.
Mi consejo: sé cuidadoso. En el título incluye la fecha y describe de forma expresiva lo que caracteriza a esta versión del código. Ten en cuenta que para recuperar esta instantánea tendrás que hacer un Get specific version por etiqueta. Y en el listado que se abre en una nueva ventana emergente, seleccionar la que almacena la versión que deseas recuperar. Por lo cual el título, cuanto más descriptivo mejor.
Aquí no se acaba
Ahora si, puedo estar haciendo diabluras en el código y romper todo lo rompible, y puedo en cualquier momento recuperar un punto específico en donde las cosas aún funcionaban de forma correcta. Pero esto, insisto, es una solución muy básica.
Los problemas empiezan a crecer cuando dos o más desarrolladores están modificando el mismo código al mismo tiempo. Ya que el sistema de etiquetas es lineal, por lo cual tarde o temprano tendremos un nudo gordiano en donde no hay forma de tener una versión estable del proyecto sin un gran y doloroso esfuerzo.
Y aquí llegamos a los troncos y las ramas: branching.
Más información | Visual Studio Team Foundation Server Branching and Merging Guide, Git. Magia Con Los Branches
En GenbetaDev | Manejo de ramas de desarrollo con git
