Introducción

En la entrada anterior os deje con la miel en los labios y solo os comente algunas generalidades sobre el control de versiones de Team Foundation Server así que ya ha llegado la hora de entrar en detalle y ver estas características.

Shelve/ Unshelve

Una de las cosas que debemos cumplir cuando trabajamos contra un repositorio de código fuente es que en el repositorio siempre debe existir una copia del código que compile.

Muchas veces supone un riesgo el que mientras un miembro del equipo trabaja en una tarea, las modificaciones que está realizando solo estén en su máquina ya que si existe algún problema con su ordenador se puede perder el código que está escribiendo. Además este código no es incluido en las copias de seguridad del repositorio que se realicen mientras los ficheros estén desprotegidos. Aplazar y Retomar cambios soluciona este problema dando la posibilidad al usuario de depositar el código en el servidor sin necesidad de protegerlo al control de versiones.

Una de las cosas que hasta ahora no he comentado es que necesitamos el Team Explorer para acceder de forma visual a las características de Team Foundation Server. Team Explorer es la herramienta de cliente que se conecta con TFS y con la cual tenemos acceso a toda la información de TFS. No solo tenemos acceso al código fuente, sino también a los elementos de trabajo, reportes o la documentación. Team Explorer viene incluido en el CD/DVD de Team Foundation Server en una carpeta llamada tfc, aunque también es posible descargarlo de la MSDN.

Supongamos que un miembro del equipo tiene desprotegidos varios ficheros sobre los que ya ha hecho modificaciones, supongamos también que proteger estos ficheros en el servidor puede provocar que el código del repositorio se desestabilice. En una situación así  lo que puede hacer el usuario para que sus cambios estén a salvo es aplazarlos. Es un proceso sencillo  parecido a la operación de protección.

Nos situamos en la solución, proyecto, carpeta o fichero que queramos aplazar y tendremos una opción en el menú contextual llamada "Aplazar cambios". También es posible hacerlo desde la ventana de Protecciones Pendientes. Una vez hecho esto nos aparecerá una ventana como la que se muestra a continuación y sobre la que realizaremos un pequeño análisis.

Aplazar cambios debe tener un nombre que identifique el conjunto de ficheros que se están aplazando, de esta forma lo podremos diferenciar a la hora de retomar el trabajo si hubiese otros conjuntos de ficheros aplazados. También tenemos la opción de añadir comentarios, enlazar el conjunto de cambios con el elemento de trabajo con el que están asociados los ficheros o incluir los nombres del revisor del código, revisor de seguridad y revisor de rendimiento. Estas opciones se pueden realizar pulsando sobre los iconos de Elementos de trabajo y Notas de protección, que aparecen a la izquierda.

Además, en las casillas que aparecen en la parte inferior izquierda, podemos seleccionar que se realice la evaluación de las políticas de protección y decidir si conservar los cambios locales o no. Estas dos casillas están mas enfocadas a un método de trabajo en el que los desarrolladores no hacen protecciones directamente sobre el control de versiones, sino que hacen aplazamientos de los cambios y luego el código es revisado por otros miembros del equipo, hasta que el encargado de hacer las protecciones las hace.