Nuevo modelo de distribución de componentes de cliente

Distribuir los componentes de cliente al equipo de cada desarrollador era uno de los aspectos de Team System sobre los que Microsoft había tenido algunas quejas y han intentado mejorar en ese aspecto. Por componentes de cliente entendemos las dlls de las políticas de checkin y las dlls de los custom controls para los tipos de workitems personalizados.

Pues bien, por un lado las políticas de checkin debían estar en cada máquina y además las rutas de la ubicación de las dlls debían estar incluidas en el registro  de Windows para que Visual Studio pudiese localizarlas. Otra opción es que las dlls de las políticas estén en la carpeta “<ApplicationData>MicrosoftTeam Foundation”, cosa que he aprendido indagando el funcionamiento de las Power Tools, todo hay que decirlo, porque no creo que hayan añadido esa funcionalidad como parte de esta release de las Power Tools. Independientemente de eso, la realidad es que esto no ha cambiado, lo que ha cambiado ha sido la forma de distribuirlas. Antes la distribución se hacia mediante un paquete de instalación que dejase las dlls en una ubicación y que insertase una clave en el registro indicando dicha ubicación o bien podíamos realizar estos dos pasos de forma manual, el fin era que TFS reconociese esas dlls como políticas y que no diesen error cuando intentábamos hacer checkin en un proyecto.

Respecto a los custom controls para los tipos de workitems personalizados la estrategia era similar, aunque no había que insertar nada en el registro si que había que dejar la dll del custom control y un fichero de metadatos .wicc en una ruta especifica, en definitiva, la forma de hacerlo era mediante un paquete de instalación o haciendo el despliegue de forma manual.

La buena noticia es que, una de las nuevas características incluidas en la ultima versión de las Power Tools ha sido una que permite almacenar estos componentes de cliente en el control de código fuente de Team Foundation Server en un directorio especial y luego hacer que se instalen en cada cliente de forma automática si el usuario tiene esta funcionalidad activada. En primer debemos activar esta nueva funcionalidad y para ello tenemos que pulsar sobre la carpeta Team Members con el botón derecho y seleccionar la opción “Personal Settings”.

PowerTools - Imagen 10

En la pantalla que aparece tenemos varias opciones, pero de momento solo nos centraremos en dos de ellas. La primera, con el texto “Install downloaded custom components”, nos permite activar la instalación automática para los componentes de cliente que tengamos en la carpeta especial que comentaba anteriormente y en la que se guardaran los componentes. La segunda de las opciones habilita la validación de los StrongNames de cada uno de los componentes antes de ser instalados. Para llevar a cabo la validación de los StrongNames de los assemblies es necesario que almacenemos todas las claves con las que han sido firmados los assemblies en la ruta “<ApplicationData>MicrosoftTeam Foundation ServerStrongNameKeys”. De esta forma se evita que alguien pueda distribuir una dll con código malicioso, por lo tanto es altamente recomendable que si marcamos la casilla para instalar automáticamente los componentes de cliente lo hagamos también con la verificación de los StrongNames.

PowerTools - Imagen 11

Por último respecto a esta pantalla solo comentaros que hay un botón con el texto “Download Now” con el que podemos forzar la descarga de los componentes simplemente pulsándolo. Este botón hará un “Get Latest Version” de la carpeta especial que os comentaba y copiará automáticamente los assemblies a la ubicación que les corresponde para que Visual Studio pueda encontrarlos cuando lo requiera.

Con esto habríamos terminado con la configuración que tiene que ver con el despliegue automático de componentes de cliente, ahora solo nos quedaría almacenarlos en el control de código fuente. Si habéis instalado ya las Power Tools, probablemente habréis observado que ahora en el control de código fuente tenemos una carpeta nueva que se llama “TeamProjectConfig”. En esta carpeta se guarda la configuración referente a los equipos que hayamos creado, distribuida en varios ficheros.

Para almacenar los componentes de cliente en el control de código fuente y permitir que Visual Studio los instale si tenemos marcada la casilla anterior lo único que tenemos que hacer es crear dos carpetas, cada una de ellas para un tipo componente, “CheckinPolicies” y “CustomControls”. Es importante indicar que si tenemos marcada la casilla para la instalación automática, los componentes de cliente se instalarán cada vez que le demos al botón “Download Now”.

PowerTools - Imagen 12

Por último, si necesitamos tener diferentes versiones de un mismo componente para diferentes versiones de Team Foundation Server, es necesario crear subcarpetas dentro de las carpetas que he comentado anteriormente, utilizando el nombre “1.0” para TFS 2005, “2.0” para TFS 2008 y “3.0” para TFS2010.

Bajo mi punto de vista esta ha sido una gran mejora, ya que la distribución de los componentes de cliente era un tema un poco tedioso. Aún me quedan algunas pruebas por hacer (sobre todo con los StrongName y políticas que usen dlls adicionales) pero en principio, un 10 para el equipo de desarrollo porque me parece una mejora que facilitará mucho el despliegue de las políticas de checkin y los controles personalzados.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?

Un poco más de Power Tools

En el último post contaba algunas de las funcionalidades de la nueva versión del las Power Tools para Team Foundation Server 2008. La verdad es que me centré únicamente en la configuración personalizada que podíamos definir para cada equipo, pero a pesar de que deje entrever las nuevas acciones que podíamos realizar sobre los miembros del equipo en una de las imágenes, nos las comente.

En esta versión han incluido una serie de acciones relacionadas con el control de código fuente. En primer lugar una acción para ver el historial de checkins de un usuario. Esta acción “Show Checkin History”, abre una ventana que muestra un listado de todos los changesets que ha generado el usuario en cuestión. Desde esta lista podemos ir al detalle de cada changeset y ver toda la información del mismo; ficheros que se protegieron en el servidor, comentarios, notas de checkin, etc…

PowerTools - Imagen 6

Otra de las nuevas acciones es la de poder ver los shelvesets de un usuario cuando pulsamos con el botón derecho sobre él. La opción se llama “Show Shelvesets” y nos muestra una lista desde la que podemos acceder a todo el detalle de cada shelveset. Además, una vez hayamos abierto la ventana, podemos utilizarla para ver los shelvesets de cualquier usuario, tan solo tenemos que introducir el nombre del usuario y pulsar sobre “Find”. Desde esta ventana se pueden además eliminar y deshacer shelvesets, lo cual plantea una comodidad interesante si se quiere implantar un modelo de revisión de código antes de que se deposite en el repositorio.

PowerTools - Imagen 7

Por ultimo en lo que respecta al control de código fuente, tenemos la opción “Show Pending Changes” que permite visualizar todos los ficheros que tiene cambiados el usuario en ese momento. Si pulsamos sobre alguno de los ficheros con el botón derecho veremos que se pueden hacer una serie de acciones típicas de control de código, Checkout, Undo o ver el Historial del fichero por ejemplo.

PowerTools - Imagen 8

Además, al igual que la funcionalidad que mostraba los shelvesets, la visualización de los datos es configurable. En esta ventana tenemos un enlace llamado “Modify Query” y que cuando pulsamos sobre el nos permite modificar ciertos parámetros para volver a consultar al control de código fuente. Podemos definir la ruta de servidor sobre la que queremos mirar los ficheros que están desprotegidos y definir si queremos hacerlo solo sobre esa ruta o hacerlo de forma recursiva. También podemos especificar los tipos de ficheros que queremos comprobar con un wildcard del estilo *.* ó *.cs por ejemplo. Además podemos filtrar por un usuario concreto o simplemente ver los ficheros desprotegidos para todos los usuarios.

PowerTools - Imagen 9

La verdad es que han incluido funcionalidades muy interesantes, no son revolucionarias pero ayudan o simplifican bastante algunas tareas.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?

Team Foundation Server Power Tools October 2008

Como ya apuntaba Luis el otro día en su blog, ya ha salido la release de Octubre 2008 de las Power Tools para TFS. En esta versión, que el equipo de producto la considera una “major release”, se han incluido varias cosas nuevas, algunas de ellas muy interesantes. Podéis descargar esta ultima versión y consultar la relación de funcionalidades incluidas aquí.

La funcionalidad que más llama la atención de esta release, es que se ha añadido a los team projects un nuevo nodo llamado Team Members. Este nuevo nodo nos va a servir para organizar e identificar la gente que trabaja en el proyecto, pudiendo añadir usuarios dentro de este nodo directamente o creando equipos dentro de éste. La verdad es que a simple vista no parece gran cosa pero puede facilitar mucho el uso de la herramienta ya que se pueden configurar una serie de elementos concretos para cada equipo.

Una de mis dudas respecto al tema de Team Members es si esta funcionalidad sería meramente organizativa o si por lo contrario se podrían asignar permisos a grupos. Tras crear el primer grupo mis dudas quedaron resueltas, cuando creas un Subteam dentro de Team Members esto crea un grupo de usuarios a nivel de Team Project dentro de TFS por lo que si se pueden asignar permisos determinados a cada grupo, aunque Microsoft recomienda que estos grupos solo sean usados como contenedores y que no apliquemos permisos sobre ellos para que no se produzcan comportamientos que no queramos relacionados con la seguridad.

En primer lugar deberíamos crear una estructura de equipos que identifiquen los diferentes roles, por ejemplo: Developers y Testers. Para crear un nuevo equipo simplemente pulsamos con el botón derecho sobre Team Members y les damos a “New Subteam” y añadimos un nombre una descripción para el equipo.

PowerTools - Imagen 1

 

Obviamente el día a día de los developers y los testers es diferente y , dejando de lado el tema de la seguridad, tener reflejados estos grupos bajo Team Members nos da la posibilidad de personalizar un poco el entorno para cada uno de los grupos. Si pulsamos con el botón derecho sobre cualquiera de los grupos, por ejemplo Developers, vemos una opción que se llama “Team Settings…”. Desde esta opción abrimos un cuadro de diálogo donde se pueden configurar cuatro elementos diferentes.

Workspace Templates

Esta funcionalidad nos permite crear una serie de plantillas de workspaces a nivel de Team Project y asignar una diferente a cada equipo. La creación de la plantilla del workspace lo único que hace es que nos permite crear el mapeo de rutas locales con rutas del control de código fuente y guardarlo para que pueda ser usado por el resto del equipo. De esta forma, cuando llega alguien nuevo en el equipo solo tiene que pulsar sobre su equipo con el botón derecho y darle a “Create Workspace” y esto usará la plantilla que se haya definido para ese equipo. Si esta opción no aparece en el menú contextual significará que no se ha definido una plantilla para la creación de Workspaces en ese equipo.

PowerTools - Imagen 2

Individual Queries

Esta opción nos permite seleccionar consultas de elementos de trabajo de entre todas las consultas de equipo que contengan la macro @me y añadirlas al menú contextual que aparece cuando pinchas con el botón derecho sobre cada miembro de un equipo. De esta forma se consigue filtrar un poco las consultas para que se pueda acceder a ellas más rápido.

PowerTools - Imagen 3

Team Queries

Esta opción es similar a la anterior, pero permite seleccionar un conjunto de las consultas de equipo y hacerlas más accesibles para un grupo. Por ejemplo el equipo de Developers usará más las consultas relacionadas con el desarrollo y los Testers usarán más las consultas relacionadas con los bugs, de esta forma se asignan cada grupo de consultas a un Team y aparecerán al pulsar sobre el grupo en cuestión con el botón derecho.

PowerTools - Imagen 4

Team Links

Por ultimo, también podemos añadir una serie de direcciones Url que puedan ser de interés para todo el equipo, como puede ser el portal del proyecto, enlaces a documentación online o recursos, en definitiva, cualquier Url que pueda resultar útil. Una vez añadidas aparecerán en el menú contextual al igual que el resto de elementos que hemos ido viendo, aunque en esta ocasión agrupados en un menú llamado “Web Links”.

PowerTools - Imagen 5

La verdad es que el equipo de producto tiene razón, esta ha sido una “major release”, ya que estas cosas que hemos visto son solo el principio. Espero poder contaros algo más sobre el resto de funcionalidades que me han parecido interesantes en los próximos días.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?