Es casi imposible hablar de equipos de desarrollo distribuidos, y no tener en cuenta los clásicos problemas de bloqueos exclusivos de archivos. Siempre sucede, que alguien se baja en modo Lock un archivo y después decide tomarse 2 días de vacaciones por un problema personal, y el resto del equipo se acuerda de toda la familia de él que bloqueo el archivo se detiene a pensar como seguir.

Con TFS podemos tener el mismo problema, pero he encontrado una herramienta gratis, que me permite sacar reportes sobre el estado de los Workspaces y su contenido.  Esta herramienta es de Attrice, y estas son sus características:

Lo pueden descargar desde aquí. Y todos los días antes de irnos podemos automatizar un proceso para "alertar" a los posibles infractores.

Saludos

El Bruno

Mas procesos agiles y obviamente, cuando uno ha invertido tanto tiempo en la creación/adaptación de una metodología para el equipo de desarrollo; los problemas que surgen no tienen nada que ver con el desarrollo en sí y la mayoría se pueden arreglar con una cerveza de por medio.

Por ejemplo, mi amigo Sergio tuvo la agradable idea de preguntarme como podía cambiar la ubicación inicial donde había bajado su código desde el Source Control de Team Foundation Server (el Working Folder de Source Safe).  Antes esta opción estaba al alcance de la mano (botón derecho), ahora está bastante más complicada está más escondida que la persona que inventó la registry, pero se puede igual.

Para cambiar la ubicación por defecto del Local Path, debemos seleccionar

1.    Menú File

2.    Source Control

3.    WorkSpaces

4.    Seleccionamos el WorkSpace que queremos cambiar y seleccionamos Edit.

5.    En la sección inferior, seleccionamos el Working Folder, editamos y seleccionamos la nueva opción.

Listo !!!

Saludos

El Bruno

Seguimos 100% ágiles utilizando Visual Studio Team System ahora integrados con Team Foundation Server y utilizando la plantilla de MSF para desarrollos ágiles ojo no confundir MSF con Médicos Sin Fronteras. Uno de los puntos mas interesantes de este proyecto, es la capacidad de integrar todo tipo de herramientas para los desarrollos ágiles en un proyecto real. Y el gran incentivo de este tipo de propuestas es la necesidad de administrar a bajo nivel, éstas herramientas.

Un ejemplo concreto es la necesidad de configurar el server de compilación (Build) para las compilaciones diarias. Con la instalación por defecto de Team Foundation Server, una vez creada una configuración para un Team Build

un error muy clásico es el siguiente:

Este error compila perfectamente las soluciones, pero no permite que las pruebas se compilen correctamente.

La solución (gracias a Buck Hodges por el dato) para esto es instalar Visual Studio Team System en el server de compilación. Obviamente esto viene explicado claramente en el WhitePaper de la licencia de Team System, pero parece que ninguno en nuestro equipo tuvo tiempo para leerlo cosa más que comprensible entre los PlayOffs de la NBA, la final de la Champions, el mundial de Alemania y Eurovision.

Una vez instalado Visual Studio, nuestro error queda corregido y por fin podemos ver el tan anhelado check verde.

Y podemos agregar una compilación exitosa a nuestro historial de compilaciones.

A partir de aquí solo queda seguir configurando los seteos de Team System.

Saludos

El Bruno

PD: a ver si tengo un poco de tiempo en estos días y nos adentramos en el fabuloso mundo de las compilaciones automáticas sin Scheduler en TFS, utilizando las tareas programadas de Windows y TFSBuild.exe.

Por fin se ha acabado la época de diseños, revisiones técnicas y otras yerbas que siempre es la parte más aburrida y en donde se pierden muchísimo tiempo en detalles inútiles, y hemos empezado a integrar 100% una metodología ágil utilizando Visual Studio Team System.

Como muchos ya saben, desde la salida de .Net hace unos años, yo creo que esta es la evolución más importante en lo que se refiere a herramientas de desarrollo de Microsoft ojo, no confundir con evoluciones del tipo Pokemon. En este nuevo enfoque, donde se contempla todo el proceso de desarrollo, todas las partes del equipo pueden utilizar Visual Studio para ser parte de este proceso. Por ejemplo, una parte de este equipo, puede utilizar los nuevos proyectos de Test de Visual Studio, para contribuir un poco con la calidad del producto final.

Pero, eso siempre y cuando no nos aparezca el siguiente error, a tratar de ejecutar los tests desde Visual Studio:

Después de amargarme bastante la tarde, y de verificar que tal vez unos AddIns de prueba no sean una buena idea en un equipo de desarrollo, pude encontrar una solución. La misma consiste en eliminar todas las settings que ya posee Visual Studio y dejarlo en “cero” igual que la eliminatoria de la NBA, San Antonio Spurs y Dallas Mavericks, hoy 3-3, que es lo mismo que cero.

Para reiniciar el IDE, debemos ejecutar el siguiente comando:

Este comando limpia nuestro IDE y nos queda como en la primera instalación. A partir de aquí, ya podremos utilizar completamente Visual Studio

Saludos

El Bruno