Team Foundation Server

Pautas para proyectos de equipo y colecciones de TFS de Visual Studio

Willy-Peter Schaub y Mike Schimmel

En el artículo de MSDN Magazine “Visual Studio TFS Branching and Merging Guidance” (msdn.microsoft.com/magazine/gg598921) la gente del equipo Rangers de ALM de Visual Studio presentó una gama de escenarios de bifurcación y orientación asociada al tema para ayudarle a realizar bifurcaciones compleja y propias del mundo real, además de combinación de entornos, para mejorar la coherencia y calidad de las soluciones y el proceso general de administración de ciclo de vida de las aplicaciones (ALM).

En resumen, los Rangers son un grupo de expertos que promueven la colaboración entre grupos de producto de Visual Studio, Microsoft Services y la comunidad Microsoft Most Valuable Professional (MVP) para resolver funcionalidades perdidas y eliminar obstáculos para la adopción de estos programas.

En este artículo, los Rangers ofrecen orientación para organizar y proporcionar lo necesario para los proyectos de equipo y las colecciones de proyectos de equipo de Team Foundation Server (TFS).

Después de leer este artículo, tendrá un grado más profundo de entendimiento sobre:

• las colecciones de proyecto de equipo y sus ventajas
• las reflexiones para elegir combinar uno o más proyectos de equipo en una sola colección de proyectos de equipo o mantenerlos en colecciones de proyecto de equipo separados
• las reflexiones para organizar proyectos de equipo y colecciones de proyectos de equipo para aumentar el aislamiento o la escalabilidad
• cómo archivar uno o más proyectos de equipo inactivos

Este artículo le ayudará a comprender cómo la organización de los proyectos y de los proyectos de equipo se ve influida por problemas tales como:

• la seguridad y el aprovisionamiento para TFS, las colecciones de proyecto de equipo y los proyectos de equipo;
• la selección de una plantilla de proceso;
• la personalización de una plantilla de proceso, lo que incluye flujos de trabajo personalizados, personalizaciones de tipo de elemento de trabajo, informes personalizados, consultas personalizadas y orientación personalizada de proceso;
• organización de equipo;
• organización de proyectos de equipo, lo que incluye áreas e iteraciones;
• reflexiones respecto a la administración de proyecto, lo que incluye hitos de proyecto y programación.

Planeación

La planeación de Visual Studio TFS generalmente comienza con la infraestructura recomendada y la estructuración de los equipos de proyecto y de las colecciones de equipos de proyecto para asegurar un sistema ALM eficaz y escalable para todas las partes interesadas.

Los proyectos de orientación de los Rangers, como Visual Studio 2010 Quick Reference Guidance (vs2010quickref.codeplex.com) y la fábrica de máquina virtual de Visual Studio 2010 y TFS 2010 (rangersvsvmfactory.codeplex.com), proporcionan conceptos, orientación y pósters de referencia rápida con el fin de brindar soporte técnico a la capacidad de planeación y para ayudar a responder la pregunta de si la infraestructura debiese ser física, virtual, o ambas.

Aunque generalmente planee y defina una colección de proyecto de equipo antes de un proyecto de equipo en el entorno de TFS 2010, analizaremos primero los proyectos de equipo.

Proyectos de equipo de Visual Studio

En TFS 2005 y TFS 2008, un solo servidor TFS puede hospedar a uno o más proyectos de equipo. Cada equipo de proyecto es esencialmente un contenedor de artefactos, lo que incluye código fuente (organizado en carpetas, carpetas bifurcadas y bifurcaciones) y contiene una o más soluciones de Visual Studio, archivos de configuración de Team Build, agentes de prueba de carga de Team Load, un repositorio opcional de SharePoint que contiene los documentos pertinentes al proyecto y aprovisionamiento de seguridad usado por un equipo para seguir y realizar un conjunto de trabajo como lo define una plantilla de proceso. El proyecto de equipo no se debe confundir con un proyecto .NET de Visual Studio, el cual consiste en toda la configuración de compilación y configuración necesaria para generar un ensamblado de Microsoft .NET Framework; una solución de Visual Studio .NET, la cual consiste en uno o más proyectos de Visual Studio .NET y define dependencias de proyecto, compila procesos y el orden; o, en su lugar, una iniciativa de proyecto programada para compilar algo a partir de un conjunto de requisitos.

Para obtener más información acerca de la creación y administración de proyectos de equipo, consulte la página de la biblioteca de MSDN “Crear y administrar proyectos de equipo” (bit.ly/eCP0yX).

Analicemos las reflexiones necesarias para organizar iniciativas de proyecto en proyectos de equipo. Los proyectos de equipo contienen la mayor unidad de trabajo asociada al desarrollo de un solo producto o línea de producto. Por ejemplo, en Microsoft, Visual Studio y Office son dos líneas de producto, cada una de ellas contenida en su propio proyecto de equipo (consulte la figura 1), puesto que el desarrollo de esas líneas de producto transcurre en líneas de tiempo diferentes con hitos y programaciones de lanzamiento distintos.

Figura 1 Proyectos de equipo de Visual Studio y Office

Es importante tomar en cuenta reflexiones respecto a aprovisionamiento y aislamiento de seguridad. Uno de los aspectos que consumen más tiempo en cuanto a la creación de nuevos proyectos de equipo es el esfuerzo necesario para aprovisionar el proyecto para que sea usado por uno o más equipos, principalmente mediante la definición de la seguridad de los usuarios, grupos y permisos que controlan el acceso a un proyecto de equipo y sus artefactos. Este esfuerzo de aprovisionamiento necesita alcanzar un equilibrio respecto a los beneficios de definir adecuadamente la seguridad en el nivel necesario de granularidad que permita que el equipo haga lo que debe hacer. Al mismo tiempo, el aprovisionamiento adecuado de seguridad protege a un equipo de proyecto y a sus activos de daño accidental o deliberado hecho por personas que no debieran realizar ciertas tareas.

Para líneas de producto con distintos hitos y fechas de lanzamiento, como Visual Studio y Office, tiene sentido organizar cada línea de producto en un proyecto de equipo diferente por aislamiento de seguridad. Es probable que los equipos de desarrollo asociados a cada línea de producto funcionen totalmente separados y es poco probable que necesiten o se les otorgue permisos de contribución o de compilación a los entornos de ambos equipos.

Para las iniciativas de proyecto con distintas metodologías; por ejemplo, una en la que un equipo escoge usar la plantilla de proyecto Microsoft Solutions Framework (MSF) para Agile Software Development versión 5.0 y el segundo equipo escoge usar la plantilla de proyecto de MSF para CMMI Process Improvement versión 5.0; es necesario separar a los equipos de proyecto, puesto que a un equipo de proyecto específico se le asocia una y sólo una plantilla de proyecto.

Para las iniciativas de proyecto que necesitan definiciones únicas para áreas e iteraciones, sugerimos separar los proyectos de equipo, puesto que un proyecto de equipo específico define una sola jerarquía de área e iteración. Una alternativa es que un equipo de proyecto puede usar áreas para organizar equipos de varias características (vea la figura 2) que compartan las mismas iteraciones (vea la figura 3). Consulte también “Project of Projects with Team Foundation Server 2010” por Martin Hinshelwood, en bit.ly/hSnHGw para ver un análisis sobre un escenario que usa áreas en lugar de tener varios proyectos de equipo pequeños.

Figura 2 Un proyecto de equipo que usa áreas para organizar equipos de características separados

Figura 3 Un equipo de proyecto con varios equipos de características que comparten la jerarquía de iteración

La configuración de desprotección de control de versiones (como desprotección exclusiva, directivas de desprotección y notas de desprotección) se configura a partir de un proyecto de equipo y esas configuraciones no son compartidas por los límites del proyecto de equipo. Si iniciativas de proyecto distintas necesitan configuraciones de control de fuente diferentes, se pueden asociar a proyectos de equipo separados.

La personalización de una plantilla de proceso incluye flujos de trabajo, tipos de elemento de trabajo (WIT), informes y consultas personalizados. Puede personalizar una plantilla de proceso que se usó para crear nuevos proyectos de equipo o personalizar la plantilla de proceso específica que usó en un equipo de proyecto; esta última implica no compartirla entre los proyectos de equipo.

El uso compartido de artefactos de proyecto de equipo generalmente se hace al bifurcar un equipo de proyecto a otro. En nuestro artículo anterior, analizamos varios enfoques para compartir código común. La mayoría de ellos implicaban bifurcación.

Como podrá ver, existen varias reflexiones que deben hacerse para decidir si los proyectos separados o las iniciativas de proyecto pueden compartir el mismo proyecto de equipo o si se deben asociar a distintos proyectos de equipo. Debe considerar esos puntos y tomar decisiones de organización de proyecto de equipo que sean las más adecuadas para su organización.

Colecciones de proyecto de equipo de Visual Studio

Pese a que los proyectos de equipo son, en alguna medida, independientes entre sí, ciertas actividades de mantenimiento de TFS 2005 y TFS 2008, como la consolidación de varios servidores de TFS en un solo servidor, eran difíciles. Lo que es más, las unidades empresariales separadas de una organización sólo podían alcanzar un aislamiento organizacional al implementar dos o más servidores TFS en la organización, lo que aumenta el costo de la infraestructura y de mantención, además de un aumento en la complejidad general.

Visual Studio 2010 presentó las colecciones de proyecto de equipo. Cada servidor TFS puede tener una o más colecciones de proyectos de equipo. A su vez, una colección de proyectos de equipo contiene uno o más proyectos de equipo. Una colección de proyectos de equipo es la unidad básica de recuperación para TFS. Desde la perspectiva de creación de copias de seguridad y restauración, una colección de proyectos de equipo es similar a una colección de sitios de SharePoint.

La referencia rápida de orientación de Visual Studio 2010 (vs2010quickref.codeplex.com) proporciona un póster de referencia rápida que le brindará ayuda para planear la nueva característica de colección de proyecto de equipo, además de los proyectos de equipo mismos. Las colecciones de equipo de proyecto proporcionan una implementación más escalable para los servidores de TFS. Una colección de proyectos de equipo en TFS 2010 es una clase de símil de un servidor de TFS en TFS 2005 o TFS 2008. Para obtener más información sobre la creación y administración de colecciones de proyectos de equipo, consulte msdn.microsoft.com\library\dd236915.

Las reflexiones respecto al aislamiento de proyectos de equipo en colecciones de equipo de proyecto incluyen escalabilidad, creación de copias de seguridad, aislamiento de seguridad y uso compartido de información entre proyectos de equipo.

La escalabilidad de los servidores de TFS es sustentada por la capacidad de equilibrar la carga las de colecciones de equipo a través de toda la estructura física de servidores de SQL y de las instancias de SQL Server, lo que permite sacar provecho de la escalabilidad y la infraestructura de equilibrio de carga que generalmente se asocia a los entornos de base de datos. Si tiene la capacidad de equilibrar la carga entre los servidores de SQL Server, podrá separar los proyectos de equipo entre varias colecciones de proyecto.

Como indiqué anteriormente, una colección de proyectos de equipo es la unidad básica de recuperación para TFS. No se puede crear copias de seguridad o restaurar proyectos de equipo individualmente. Si necesita capacidades de copia de seguridad y recuperación granulares (por ejemplo, si no desea restaurar más de un solo proyecto de equipo), la organización puede aislar los proyectos de equipo en colecciones de proyecto de equipo separadas para fines de creación de copias de seguridad y restauración.

Puede tomar tiempo el proporcionar seguridad para colecciones de proyecto si se administra adecuadamente y con el grado de control y granularidad adecuado. A medida que agregue nuevas colecciones de proyecto de equipo, debe considerar el esfuerzo inicial y persistente que significa proporcionar esto a cada una de aquellas colecciones. Si los equipos de proyecto que trabajan en los equipos de proyecto administrados en un servidor de TFS tienen distintos requisitos de seguridad, puede aislarlos en distintas colecciones de equipos de proyecto para fines de seguridad.

Por otra parte, si los equipos de proyecto de los equipos de proyecto que se están administrando en un servidor de TFS no necesita aislamiento de seguridad, puede integrarlos en la misma colección de proyecto de equipo (vea la figura 4).

Figura 4 Uso compartido y límites de aislamiento de colecciones de proyecto de equipo

Si bien el uso compartido de artefactos (como los archivos de código fuente) puede hacerse entre proyectos de equipo en las misma colección de proyecto de equipo, no se pueden compartir a través de límites de colección (vea la figura 4). Si dos equipos de proyecto deben compartir artefactos, ambos deben estar contenidos en la misma colección de proyecto.

No se analizará en este artículo el uso de colecciones de proyectos de equipo para compartir y aislar código fuente, bifurcación y combinación. Le sugerimos consultar tfsbranchingguideiii.codeplex.com para obtener análisis e información asociada que se incluirá en orientaciones futuras.

Estrategias de archivado de proyectos de equipo

Es fundamental realizar mantenimiento periódico, puesto que un entorno de TFS no se puede instalar en recursos físicos ilimitados. Los administradores deben planear mantenimientos periódicos para archivar datos de proyectos completados de manera que disminuya la presión impuesta a los servidores, antes de que esto se transforme en un problema de rendimiento para equipos de desarrollo.

La orientación de actualización de los Rangers (vs2010upgradeguide.codeplex.com) define un número de estrategias posibles como parte de la orientación de actualización, de forma similar al procedimiento que desarrollaron los Servicios de consultoría de Microsoft (vea la figura 5):

Figura 5 Posible estrategia de archivado

1. Empiece haciendo una copia de la colección de proyecto de equipo.
2. Elimine los proyectos de equipo activos de la colección de proyectos de equipo archivados que se acaban de clonar (mediante la utilidad de línea de comando de TFSDeleteProject).
3. Elimine los proyectos archivados de la colección (activa) de proyectos de equipo original.
4. La nueva colección de equipo de proyecto puede almacenarse en medios externos, como medios de cinta o flash. Si se audita el sistema, los medios de archivo se pueden restaurar fácilmente para esa finalidad.
5. Separe la nueva colección de proyecto de equipo para obtenerlo fácilmente más tarde.

En principio, esto puede parecer una estrategia trivial, pero exige una directiva para determinar cuáles proyectos de equipo se pueden archivar y cuáles no. Observe con atención que las bifurcaciones del código fuente se eliminan del sistema cuando se realiza la acción TFSDeleteProject, lo cual no se puede deshacer.

A continuación se enumeran sugerencias para una directiva de archivo:

• Establezca una directiva de conclusión de proyecto para que los equipos de proyecto eliminen los datos de proyecto y los almacenen. El código fuente no es el único material que debe guardarse. Los requisitos de proyecto son interesantes, pero probablemente no estén en un formato reutilizable o uno que permita hacerle mejoras. Las especificaciones funcionales necesitan mezclarse con las anteriores para reflejar el estado del producto tal cual está al terminar el proyecto. El requisito para este proyecto se puede archivar sin preocuparse de perder datos. Los elementos de trabajo no se pueden combinar desde un equipo de proyecto a otro como se puede hacer con el código fuente, de manera que será necesario tomar decisiones respecto a cómo almacenar elementos de trabajo completos después de terminar un proyecto.
• Envíe una solicitud estándar a todos los equipos que les haga saber que hay una acción de archivamiento pendiente antes del evento, que indique a todos los equipos de proyecto definidos para ello.
• Establezca una carpeta de hitos en cada proyecto de equipo que sirva como contenedor para los datos de proyecto finales de una iniciativa de proyecto completa, que incluya listas de requisitos, informes finales de proyecto y cualquier documentación a ser guardada de acuerdo con las políticas de metodología normales para la conclusión de proyecto.

En esencia, se debe preservar todos los datos de proyecto y no solo el código fuente para que el archivamiento se haga correctamente.

Es necesario separar las colecciones de proyecto de equipo para reaccionar a una posible separación de una unidad empresarial en dos o más entidades administradas. En este escenario, se usa un enfoque similar que aquel que se usa para archivar proyectos de equipo, aunque no se va a archivar ninguno de los equipos de proyecto. La segunda colección de equipos de proyecto se deberá tratar como la original, en cuanto a que necesitará que se le realice mantenimiento periódico por separado que el que se realiza a la colección de proyecto de equipo original.

No es fácil mover proyectos de equipo entre colecciones de proyectos de equipo y, una vez que se hace la separación de la colección, no se pueden volver a combinar, sino que deben agregarse como nuevos proyectos de equipo a una colección. Para combinar colecciones de proyectos de equipo, es necesario usar código personalizado mediante la API de TFS para copiar los datos de proyecto desde una colección hasta otra.

 Si bien no es recomendado, se puede usar TFS Integration Tools para combinar proyectos de equipo como colecciones de proyecto de equipo. Consulte la documentación de TFS Integration Tools (bit.ly/9tHWdG).

En un artículo futuro, investigaremos cómo los Rangers superan y administran los desafíos de la administración de equipos Agile distribuidos mediante las herramientas de ALM de Visual Studio.

Willy-Peter Schaub es un administrador de programas senior de los Rangers de ALM de Visual Studio en el Centro de desarrollo canadiense de Microsoft. Desde mediados de la década de 1980, ha emprendido una búsqueda por la simplificación y el facilitamiento de mantención en la ingeniería de software. Podrá encontrar su blog en blogs.msdn.com/b/willy-peter_schaub y podrá seguirlo en Twitter en twitter.com/wpschaub.

Mike Schimmel es un arquitecto de soluciones de ALM de los arquitectos de servicios de consultoría estadounidenses de Microsoft y es un miembro fundamental de los Rangers de ALM de Visual Studio. Tiene cerca de 25 años de experiencia en el estudio y la práctica de ALM, desde investigación y consultoría hasta venta competitiva de productos y entrega de servicios.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Bill Essary, Bill Heys,Martin Hinshelwood,Bijan Javidi y Mario Rodriguez