teamsystem.es

¿Es importante hacer Check-in cada día?

gsus — Thu, 04 Dec 2008 22:16:38 +0200

A raíz de un Workshop que hice este martes en Microsoft, me he decidido a escribir un post, que aunque tiene su parte técnica, es más bien una filosofía. Una de las prácticas recomendadas por Martin Fowler en su articulo Continuous Integration (revisión de Mayo 2006) es que se realice al menos un Check-in de código en el repositorio al día y esta sugerencia tiene varias razones con las que yo estoy bastante de acuerdo.

En primer lugar, si depositamos código en el repositorio al menos una vez al día, nuestro código estará seguro ante una catástrofe en nuestro equipo, si llevásemos una semana sin subir nada al repositorio y por cualquier motivo se estropease nuestro disco duro sería bastante duro tener que volver a repetir todo el trabajo, sin embargo subiendo el código al menos una vez al día éste pasaría a formar parte del backup diario de nuestro repositorio con lo que en el peor de los casos perderíamos solo el trabajo del último día. Además mientras menos cantidad de código subamos al repositorio cada vez, menos costosa será la integración del mismo con el código que ya hay en el repositorio, es decir, menos tiempo entre cada subida == menos código que integrar == menos problemas de integración.

Por otro lado, el subir código, no una, sino varias veces al día, da una sensación de progreso increíble. Es algo más psicológico, pero el ir cerrando pequeñas tareas da la sensación de rendir mucho y eso es positivo. El problema muchas veces viene dado por que se estiman tareas que duran más de un día y obviamente subir algo incompleto al repositorio y que pueda causar inestabilidad no es buena idea. En estos casos lo mejor sería intentar por todos los medios dividir esas tareas en subtareas, para que el tiempo de cada una de ellas este por debajo de un día y así poder usar es práctica.

Entorno a esta idea, y solo para trastear un poco con la API de Team Foundation Server, he desarrollado una pequeña utilidad (por ahora en versión 0.1) que teniendo una solución abierta en Visual Studio detecta si la solución esta enlazada a Team Foundation Server y si es así obtiene cada uno de los proyectos de la misma y mira los Check-ins que hubo sobre cada uno de los ficheros en las últimas 24 horas. Es una versión muy de pruebas aún, y tengo que ver cual es la forma óptima de obtener los ultimos check-ins del repositorio, pero para soluciones de un tamaño medio funciona a la perfección.

No es el objetivo de este post entrar en los detalles técnicos de como esta hecha, pero es una clase, que quitando comentarios, ronda las 160 ó 170 lineas, así que la complejidad no es mucha y es fácil de entender. Yo la tengo configurada como una herramienta externa dentro de Visual Studio y le paso como parametro directamente la ruta de la solución que esta abierta, así es mucho más cómodo que ejecutarla desde línea de comando. Os dejo una captura para que la veáis, y por su puesto un zip con el código fuente.

Y aquí tenéis el zip con el código fuente: CheckCISolution.zip

Se aceptan sugerencias!!

Nuevo modelo de distribución de componentes de cliente

gsus — Wed, 12 Nov 2008 23:45:01 +0200

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>\Microsoft\Team 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".

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>\Microsoft\Team Foundation Server\StrongNameKeys". 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.

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".

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.

Un poco más de Power Tools

gsus — Mon, 10 Nov 2008 22:17:18 +0200

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...

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.

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.

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.

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

Team Foundation Server Power Tools October 2008

gsus — Sun, 09 Nov 2008 23:57:02 +0200

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.

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.

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.

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.

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".

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.

¿Necesitamos más plantillas de proceso?

gsus — Sun, 26 Oct 2008 19:45:49 +0200

Uno de los puntos fuertes de Visual Studio Team System es que cuando creamos nuestros proyectos nos permite seleccionar la metodología con la que se gestionará el mismo. La metodología que elijamos marcará como distribuiremos y planificaremos todas las tareas necesarias para llevar a cabo el proyecto. Ya que existen una gran cantidad de metodologías y para hacer el producto lo mas versátil posible, se dotó a VSTS con un mecanismo para poder crear nuevas plantillas que definieran los procesos de cualquier metodología. Al producto la acompañan dos plantillas de proceso diferentes, la de MSF for Agile y MSF for CMMI, pero existen muchas otras plantillas, algunas creadas por Microsoft, como eScrum u otras de terceros como puede ser la famosa Scrum For Team System de Cochango. Algunas de estas plantillas han sido creadas como proyectos de código abierto, otras son simplemente gratuitas y también las hay de pago.

A pesar de la gran cantidad de plantillas que existen, la gran mayoría de ellas bajo mi punto de vista (y que conste que no soy un experto en metodologías ni mucho menos) están mas enfocadas al ciclo de creación de un nuevo software que al mantenimiento del mismo. Si bien Scrum por ejemplo puede ser utilizado para la gestión de Bugs, ya que solo dice como hay que organizarse no que estamos organizando, la realidad es que el departamento de desarrollo de nuevas aplicaciones y el de mantenimiento de las mismas se gestionan de formas muy diferentes normalmente. Por ejemplo, en muchas ocasiones los que nos dedicamos a la consultoría llegamos a un cliente hacemos un desarrollo a medida y es el cliente final el que se encarga de su mantenimiento.

Una vez que esta aplicación esta lista y pasa a un estado de mantenimiento, la mayoría de tareas que se hacen, basándome en mi experiencia, es bug fixing. Suele existir un grupo de personas que se encargan de trasladar los bugs encontrados por los usuarios al equipo de mantenimiento y estos en base a su criticidad, impacto o tipo asignan prioridades para la resolución de los mismos. En este punto el proceso se convierte en algo parecido a una cola donde se van apilando bugs y se van desapilando en base a su prioridad, ya no existen áreas e iteraciones, o sprints, no existe una fecha final, ni unos requisitos específicos, solo que corrijan los bugs de la versión que hay en producción y que los usuarios puedan utilizar el producto. Quizá esta visión este mas enfocada a esa gran cantidad de herramientas que poseen las compañías para la gestión interna de sus procesos y menos a un software que se venda como producto a un usuario final, pero este escenario que planteo es muy común y creo que todos lo hemos visto o vivido.

Llegados a este punto la pregunta es, ¿necesitamos nuevas plantillas de proceso?

A mí se me ha planteado este escenario recientemente y tras evaluar como gestionarlo con Scrum o con cualquier otra metodología, mi decisión ha sido crear una nueva plantilla de proceso. Para llegar a esta decisión me plantee una serie de preguntas y analice como de factibles eran con cada una de las opciones, plantilla nueva o una existente.

Por ejemplo, ¿cuando finaliza el desarrollo? ¿tenemos un objetivo claro?. Ante estas dos preguntas las respuestas son que no tenemos una fecha de fin ni un objetivo claro que alcanzar, solo que se corrijan los bugs que se encuentren. Si usasemos una plantilla existente de una metodología no podríamos crear sprints o áreas e iteraciones, porque no hay un objetivo tangible que alcanzar ni en una fecha concreta. En este aspecto, mi opinión es que al no haber un objetivo claro ni puntos en el tiempo que vayan marcando hitos, una metodología que se base en estas cosas no es adecuada, por lo tanto usar una plantilla ya existente es bastante complicado.

Pero si obviasemos el aspecto que he comentado anteriormente y optasemos por una plantilla existente, nos surgirían otros temas como por ejemplo si nos sirven o no los tipos de WorkItems de la plantilla. Ahora necesitamos información de otro tipo, como los datos aportados por el usuario, si sabe como replicar el bug, comentarios entre los que recogen los bugs que encuentran los usuarios y los desarrolladores, en definitiva, un montón de datos adicionales que requerirían de la personalización o creación de un nuevo tipo de Work Item.

O también los tipos de reportes que necesitaría. En este aspecto ya no tienen mucho que ver los reportes que pueda aportarme una plantilla de Scrum como en Burndown chart o el Project Velocity de MSF Agile. Ahora quizás necesite ver cual es la tipología de los bugs, o el volumen de bugs solucionados por fechas, o porque no, el número de bugs que soluciona cada desarrollador, cuantos bugs se han rechazado, un punto de vista quizás mas enfocado al pasado-presente, que al presente-futuro que aportan las metodologías donde se tiene un objetivo que alcanzar.

A raíz de esto es muy probable que ponga posts relacionados con la creación y edición de plantillas de proceso, pero si me gustaría que antes de crear una plantilla de proceso os hagais estas y más preguntas para determinar si realmente necesitáis una plantilla de proceso. Yo a día de hoy aun no estoy seguro de si la decisión es correcta o no y eso lo iré viendo con el tiempo, por eso me gustaría lanzaros varias preguntas, ¿que opináis vosotros de todo este asunto? ¿os parece correcto usar Visual Studio Team System para este tipo de gestión? ¿creéis que es necesaria la creación de mas plantillas de proceso?

Mejorar el rendimiento de nuestras Builds

gsus — Wed, 22 Oct 2008 01:01:01 +0200

Una de las prácticas de la Integración Continua que recomienda Martin Fowler es la de mantener lo más rápidas posibles nuestras Builds, aunque también podemos hacer aplicable esta práctica a todas nuestras Builds, no solo las de Integración Continua. Normalmente uno de los pasos en los que más suelen tardar las Builds es a la hora de obtener el código del repositorio y preparar el entorno para compilar, teniendo que limpiar el contenido de la última Build, regenerar el Workspace y obtener la ultima versión del código.

Tal y como ya contó el gran Luis Fraile en un post hace tiempo, lo ideal para mejorar el rendimiento es evitar que se realicen estos pasos que he comentado anteriormente añadiendo una serie de propiedades dentro de nuestro fichero TFSBuild.proj para hacer lo que se denomina Builds Incrementales. Este tipo de Builds se configuran para que solo se obtengan los ficheros modificados sobre los últimos que ya había en el Working Directory del Build Agent con lo cual se ahorra bastante tiempo. Si habéis leído el post de Luis (lectura recomendada), con Team Build 2005 se utilizaban 3 propiedades para configurar este tipo de Builds Incrementales.

<Project>
  <PropertyGroup>
    <SkipClean>true</SkipClean>
    <SkipInitializeWorkspace>true</SkipInitializeWorkspace>
    <ForceGet>false</ForceGet>
  </PropertyGroup>
</Project>

En Team Build 2008 han simplificado este proceso, que era bastante utilizado, por una sola propiedad llamada IncrementalBuild que simplemente tenemos que establecer a "true" y hará el mismo efecto que las 3 propiedades que teníamos que establecer en la versión anterior.

<Project>
  <PropertyGroup>
    <IncrementalBuild>true</IncrementalBuild>    
  </PropertyGroup>
</Project>

Simplemente con esto ya tendríamos nuestras Builds configuradas y probablemente hayamos ganado algo de velocidad a nivel global en el proceso de la Build.

ALM Workshops: Integración continua con TFS 2008

gsus — Mon, 20 Oct 2008 23:30:47 +0200

Tras el evento que celebró Microsoft Ibérica la semana pasada en Madrid , el ALM Sessions 08, donde se impartieron multitud de sesiones, obviamente acerca de ALM, llegan una serie de Workshops llamados los ALM Workshops. Esta serie de eventos, que se celebrarán en Madrid y Barcelona durante Octubre, Noviembre y Diciembre, no hacen mas ampliar considerablemente (de 45 minutos a 4 horas) los contenidos presentados en dicho evento. A pesar de que no participe como ponente en ese evento (llegamos tarde), si que voy a ser ponente en uno de esos Workshops.

Este próximo Miércoles tendrá lugar el primero de esos Workshops y yo voy a ser el encargado de darlo. En él hablaré de como adoptar la Integración Continua con Team Foundation Server 2008. El enfoque será bastante practico y la intención es pasar la mayor parte del tiempo con Visual Studio y configurando todo el entorno para adoptar la Integración Continua de la forma más eficiente posible. Por aquí os dejo los datos de registro y la url por si alguno quiere/puede asistir.

Evento: Workshop ILITIA: Integración Continua con Team Foundation Server 2008
Fecha: Miercoles 22 de Octubre, de 10:00h a 14:00h
Lugar: Oficinas de Microsoft Ibérica en Pozuelo de Alarcón, Madrid
Coste del evento: 30€

Laboratorios Virtuales de Visual Studio Team System 2008

gsus — Tue, 07 Oct 2008 23:11:17 +0200

Yo no soy muy partidario de poner posts con simplemente con links sin generar algún tipo de valor adicional, pero en esta ocasión voy a hacer una excepción. A finales de Marzo de este año Microsoft publico una máquina virtual muy completa con la versión RTM de Visual Studio Team System 2008 y de la que ya he hablado anteriormente. Junto a esta máquina virtual se publicaron también una serie de laboratorios con los que se podían ver y aprender muchas de las nuevas características del producto.

Pues bien, hoy he visto (y hasta ahora no había tenido constancia de ello) que algunos de estos laboratorios y otros nuevos están disponibles online, y que sin necesidad de descargar nada podéis realizarlos tranquilamente desde vuestro PC, en casa o en la oficina. Así que si más demora aquí os dejo los enlaces a estos laboratorios para podáis hacerlos.

Y bueno por si esto os parece poco, aprovecho también para dejaros unos enlaces a una serie de Web Casts que se han publicado los chicos del programa de partners y que están bastante bien:

Microsoft® Visual Studio® Team System 2008 : Serie de 6 Web Casts de una hora de duración cada uno que da un repaso a cada una de las versiones de VSTS así como a Team Foundation Server. Estos Web Casts están clasificados como nivel avanzado.
Microsoft Visual Studio Team System 2008 : Serie de otros 6 Web Casts de una hora de duración, y que en esta ocasión además de repasar las distintas versiones de VSTS y Team Foundation Server, ofrece una introducción a ALM. Estos son algo más leves en cuanto a contenidos, son de nivel intermedio.
Visual Studio Team Systems Web Seminar Series : Y por ultimo, una serie de Web Seminars, mucho más introductorios y que hacen un recorrido por las novedades del producto analizando cada una de las versiones de VSTS.

Y para concluir (y os prometo que ya paro de poner enlaces :-)) os dejo también la url de la pagina de eventos y web casts dedica a Visual Studio Team System donde se van publicando los nuevos Web Casts y laboratorios que van sacando del producto, ya hay incluso un Web Cast planeado para Marzo de 2009.

Visual Studio Team System- Power in Simplicity

Espero que os sean de ayuda todos estos recursos de formación.

Excluir el código generado de la cobertura de código

gsus — Fri, 03 Oct 2008 01:02:44 +0200

Una de las características que nos proporciona Visual Studio Team System es la Cobertura de código, que nos ayuda a saber que cantidad de código funcional cubren nuestras pruebas unitarias. El volumen de código que cubren nuestras pruebas es representado de forma porcentual y como cabe esperar lo ideal es mantener este porcentaje lo más alto posible, pero muchas veces debido al código que genera Visual Studio en algunas ocasiones, este porcentaje nunca alcanza el 100%.

Cubrir el 100% del código con nuestras pruebas unitarias es una tarea muy difícil pero si además tenemos código generado, que no debemos probar, y que también es contabilizado, podemos perder la perspectiva del nivel de cobertura que estamos alcanzando con nuestras pruebas. Lo ideal sería, al igual que se puede hacer con las reglas de Análisis estático de código, excluir el código generado del informe de cobertura de código, ¿no?.

Pues bien, a pesar de que no es una funcionalidad tal cual, es más bien un Workaround, existe la forma de excluir el código generado para que no contabilice cuando se esta realizando la cobertura de código, incluso hacer que el código generado no aparezca en el reporte de cobertura de código. El Tip/Trick/Hack o como queráis llamarlo surge a raíz de como es realizada la medición de la cobertura, que se basa en el Debugger para saber porque líneas de código se ha pasado, con lo que si conseguimos que el Debugger no pase por el código generado evitamos que ese código sea contabilizado, pero voy a dejar ya de dar tanto detalle y vamos a ver un poco de código.

Partiendo de un proyecto de librería de clases recién creado, tenemos una clase con el código que sigue:


using System;
using System.Collections.Generic;

namespace Managers
{
    public class ManagerClass
    {
        public List<Book> GetBooksByName(string bookName)
        {
            return null;
        }
    }
}

Este código no hace absolutamente nada, con lo que si generamos un test unitario con el código que se muestra a continuación deberíamos obtener una cobertura del 100%, ¿no?

[TestMethod]
public void GetBooksByNameExpectedNull()
{
    // Arrange
    ManagerClass target = new ManagerClass();

    // Act
    List<Book> val1 = target.GetBooksByName(String.Empty);

    // Assert
    Assert.IsNull(val1);
}

Sin embargo tras ejecutar la prueba unitaria, obtenemos a nivel de ensamblado un 28,57% de cobertura, lo cual resulta un poco extraño. Si miramos el reporte de la cobertura de código vemos que el espacio de nombres Managers si tiene una cobertura del 100%, pero tenemos un tal Managers.Properties que representa una parte importante de nuestro código y que no esta probado, lo que hace que la media porcentual caiga en picado.

La clase Settings dentro de Managers.Properties es código generado por Visual Studio y en este ejemplo representa un porcentaje muy alto de todo el código que hay en el proyecto, lo que hace que al no estar probado, nuestro índice de cobertura sea muy bajo. Para excluir este código de la medición lo único que tenemos que hacer es abrir el fichero Settings.cs y añadir, en este caso a nivel de clase, el atributo DebbugerNonUserCode o DebuggerHidden, con lo que el depurador no pasará por ese código y no se incluirá en el reporte.

using System.Diagnostics;

namespace Managers.Properties 
{    
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute(
        "Microsoft.VisualStudio.Editors.SettingsDesigner." +
        "SettingsSingleFileGenerator", "9.0.0.0")]
    [DebuggerNonUserCode] /* Atributo para la exclusion */

    internal sealed partial class Settings 
        : global::System.Configuration.ApplicationSettingsBase 
    {
        private static Settings defaultInstance = 
            ((Settings)(global::System.Configuration.
            ApplicationSettingsBase.Synchronized(new Settings())));
        
        public static Settings Default 
        {
            get 
            {
                return defaultInstance;
            }
        }
    }
}

Como podéis comprobar en la siguiente imagen ya no hay rastro de Managers.Properties y nuestro porcentaje a nivel de ensamblado ya es real.

Este es un ejemplo muy básico, y la proporción entre código funcional y código generado hace que no probar el código generado tenga mucho impacto, pero muestra como conseguir el objetivo del post perfectamente. Si lo probáis en un proyecto en el que tengais DataSets, o referencias a servicios Web podréis observar el resultado real.

Por ultimo, solo comentar que si decidimos usar este método para obtener una cobertura de código real, debemos tener presente que el código que este marcado con este atributo no cuenta en ningún aspecto para el depurador, con lo que si necesitamos poner un punto de interrupción en este código, éste será obviado por completo. Además si Visual Studio necesitara regenerar el código, por ejemplo una referencia a un servicio Web o un DataSet, como es lógico los atributos se borrarán y el código volverá a aparecer en el reporte de cobertura.

Diccionarios para el Análisis estático de código (II)

gsus — Mon, 29 Sep 2008 01:06:49 +0200

En el post anterior habíamos visto la estructura de un diccionario personalizado para el Análisis estático de código, pero en la mayoría de los casos puede llegar a ser un auténtico incordio tener que crearlo sin ningún tipo de ayuda, ya que se trata de un fichero Xml sin más. Una de las cosas que podemos hacer en Visual Studio es tener referenciados una lista de esquemas Xsd que nos aportan intellisense a la edición de los ficheros, así que basándonos en el fichero de diccionario que acompaña a Visual Studio vamos a generar un Xsd para que nos ayude en la edición de este tipo de archivos. Para generar un Xsd, tan solo tenemos que abrir el fichero Xml en Visual Studio e irnos al menú XML y seleccionar la opción Generate Schema. Este esquema nos servirá como base y con unas pequeñas modificaciones en los números de ocurrencias de los nodos y añadiendo el "Target Namespace" ya lo tendremos listo para utilizar. Como yo ya lo tengo hecho, lo he colgado para que lo podáis descargar directamente. (CodeAnalysisDictionary.xsd)

Una vez hemos creado el esquema lo único que tenemos que hacer para dar soporte a la edición de los ficheros de diccionarios es agregar el esquema generado a la lista de esquemas de Visual Studio desde la opción de menú "XML -> Schemas..." y veremos como ya nos aparece en la lista y como tiene el Target Namespace que le hemos asignado: "http://microsoft.com/schemas/VisualStudio/CodeAnalysis".

Y por último, ya solo nos quedaría crear un fichero Xml, poner el valor "http://microsoft.com/schemas/VisualStudio/CodeAnalysis" al atributo "xmlns" del nodo raíz y Violá! ya tenemos intellisense para la edición de nuestros ficheros de diccionarios.

Por último, y para no extenderme mucho más, solo comentaros que una vez tengamos creado nuestro fichero Xml con todos los términos, no es necesario que lo copiemos a cada uno de los proyecto, lo cual nos complicaría un poco el tema del mantenimiento en caso de que quisiésemos añadir nuevos términos al fichero, por lo que una de las soluciones para este caso pasa por poner el fichero Xml a nivel de solución y añadir el fichero a cada proyecto, pero no como un fichero físico, sino como un link al fichero, para solo tener un fichero y que sea fácil de mantener.

Y con esto concluye este segundo post dedicado a la creación y uso de diccionarios personalizados para el Análisis estático de código, espero que os sea de ayuda.

Diccionarios para el Analisis de estatico de codigo (I)

gsus — Fri, 26 Sep 2008 00:14:00 +0200

Una de las mejoras que incluye Visual Studio Team System 2008 es el soporte para diccionarios propios en cuanto a la ejecución de las reglas de análisis de código estático se refiere. A pesar de que es una de las funcionalidades que aparece en la mayoría de las listas de nuevas características del producto no es del todo fácil encontrar información detallada acerca de como funciona.

Solo para refrescar un poco la memoria, os comento que el Análisis estático de código, es una funcionalidad que ofrece Visual Studio Team System desde la versión 2005 y que antes podíamos utilizar desde una herramienta externa llamada FxCop. Esta funcionalidad nos permite definir un conjunto de reglas que serán verificadas sobre nuestro código y que varían en cuanto a objetivo. Podemos encontrar reglas relacionadas con el rendimiento, el diseño de nuestras APIs, la portabilidad de nuestro código, mantenibilidad o el caso sobre el que me centraré en esta entrada, el nombrado de los elementos públicos de nuestro código, ya sean interfaces, clases, métodos o propiedades.

Visual Studio Team System viene acompañado de una serie de reglas de nombrado que podemos activar a voluntad y que van desde sugerirnos no utilizar guiones bajos o el correcto uso de mayúsculas y minúsculas, hasta que no usemos variables en los métodos con el mismo nombre que los miembros de una clase. Pero si prestamos atención a las reglas de nombrado (Naming Rules), estas nos sugieren muchas cosas relacionadas con los nombres que usamos para los elementos públicos de nuestro código y se basa en el diccionario de palabras de Word para realizar el análisis, aunque no es necesario tener Word instalado ya que dentro de la carpeta del Análisis estático de código viene incluido ya el diccionario. Sin embargo para los casos en los que este diccionario no sea suficiente se nos permite tener un diccionario personalizado de palabras contra el que el motor de Análisis estático de código realizará las comprobaciones necesarias.

Para añadir un diccionario personalizado lo único que tenemos que hacer es agregar un fichero Xml a nuestro proyecto y cambiar el valor de la propiedad Build Action del fichero y ponerlo a CodeAnalysisDictionary, de esta forma cuando se ejecute el análisis estático de código se verificarán la palabras contra el diccionario que acabamos de crear.

El fichero Xml tiene una estructura determinada y en él se nos permite añadir una lista de palabras validas, no validas, palabras en desuso y su alternativa actual, una lista de palabras compuestas, una lista de excepciones para palabras compuestas y por ultimo una lista de excepciones para acrónimos de palabras, aunque veremos cada uno de los puntos en detalle. Si queréis ver un fichero Xml completo bien formado y documentado os recomiendo que vayáis a la ruta "C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop" donde podéis encontrar un fichero llamado "CustomDictionary.xml" que viene con el propio Visual Studio. A continuación os describo cada unos de los tipos de listas que podemos encontrar dentro de este fichero:

Palabras reconocidas: Lista de palabras que a pesar de no estar en el diccionario interno no provocarán un error del tipo CA1704. Esta lista de palabras no es sensible a mayúsculas y minúsculas y debemos evitar añadir palabras compuestas en esta lista.

<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Words>
    <Recognized>
      <Word>accessor</Word>
      <Word>accessors</Word>
      <Word>acos</Word>      
      ...
      <Word>xsi</Word>
      <Word>xsl</Word>
      <Word>xslt</Word>
    </Recognized>
  </Words>
</Dictionary>

Palabras no reconocidas: Lista de palabras que a pesar de estar incluidas en el diccionario se quiere evitar su uso. Estas palabras, al igual que las reconocidas, no son sensibles a mayúsculas y minúsculas y debemos evitar introducir palabras en desuso en esta lista. En caso de que usemos alguna de las palabras incluidas en esta lista provocaremos que la reglas CA1704 genere un Warning o un Error en base a nuestra configuración.
```
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Words>
    <Unrecognized>
      <Word>cb</Word>
      <Word>ch</Word>
      <Word>gt</Word>
      <Word>idx</Word>
      ...
      <Word>tw</Word>
      <Word>val</Word>
  </Unrecognized>
  </Words>
</Dictionary>
```

Términos en desuso: La lista de términos en desuso, como cabe esperar, contiene una lista de palabras que no deberían usarse, pero además prove de una palabra alternativa que se debería usar. En caso de que una de las palabras de la lista este en nuestro código y sea de visibilidad pública hará que la regla CA1726 no sea valida. Los términos de esta lista no son sensibles a mayúsculas y minúsculas, pero la palabra alternativa sugerida debería tener una nomenclatura Pascal-Case y en caso de que no tengamos palabra sugerida simplemente podremos dejarla en blanco.

<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Words>
    <Deprecated>
      <Term PreferredAlternate="EnterpriseServices">complus</Term>
      <Term PreferredAlternate="Canceled">cancelled</Term>
      <Term PreferredAlternate="Indexes">indices</Term>
      <Term PreferredAlternate="LogOn">login</Term>
      <Term PreferredAlternate="LogOff">logout</Term>
      <Term PreferredAlternate="SignIn">signon</Term>
      <Term PreferredAlternate="SignOut">signoff</Term>
      <Term PreferredAlternate="">flag</Term>
      <Term PreferredAlternate="">flags</Term>
    </Deprecated>
  </Words>
</Dictionary>

Palabras compuestas: La lista de palabras compuestas y la alternativa asociada es usada por la regla CA1702 y el motivo de esta lista es que aun siendo palabras compuestas existen en el diccionario como palabras únicas pero sin embargo deberían ser usadas como dos palabras con el correspondiente uso de mayúsculas y minúsculas. Por ejemplo la palabra "Filename" existe en el diccionario, pero el uso correcto tratándose de código debería ser "FileName". Cualquier palabra que se encuentre en esta lista es automaticamente añadida a la lista de palabras DiscreteExceptions que veremos a continuación, ya que si no estuviesen añadidas nunca llegarían a generar un error y no se podría sugerir la alternativa correspondiente.
```
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Words>
    <Compound>
      <Term CompoundAlternate="AutoScrolls">autoscrolls</Term>
      <Term CompoundAlternate="AutoComplete">autocomplete</Term>
      <Term CompoundAlternate="AutoCompletes">autocompletes</Term>
      <Term CompoundAlternate="AutoSave">autosave</Term>
      <Term CompoundAlternate="AutoSaves">autosaves</Term>
      <Term CompoundAlternate="JavaScript">javascript</Term>
      <Term CompoundAlternate="JScript">jscript</Term>
    </Compound>
  </Words>
</Dictionary>
```
Excepciones discretas: Como he comentado anteriormente, en esta lista se encuentran las palabras que a pesar de estar en el diccionario son palabras compuestas y dado que las listas no diferencian entre mayúsculas y minúsculas, se añaden en esta lista las palabras para que la regla CA1702 no genere un falso positivo y sugiera al usuario cambiar la "AutoComplete" por la palabra "AutoComplete".
```
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Words>
    <DiscreteExceptions>
      <Term>onset</Term>
      <Term>inset</Term>
      <Term>byname</Term>
      <Term>setout</Term>
      <Term>countertype</Term>
    </DiscreteExceptions>
  </Words>
</Dictionary>
```
Acrónimos: Por último, si bien las listas anteriores eran listas de palabras, esta lista es de acrónimos. En ella incluiremos abreviaturas que por un motivo u otro no deban seguir las reglas de nombrado estándares, como por ejemplo el acrónimo del número matemático "Pi", que según los estándares de nombrado al ser de dos letras debería ir en mayúsculas, como "IO" por ejemplo.
```
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Acronyms>
    <CasingExceptions>
      <Acronym>Pi</Acronym>
      <Acronym>Na</Acronym> 
      <Acronym>NESW</Acronym> 
      <Acronym>NWSE</Acronym> 
    </CasingExceptions>
  </Acronyms>
</Dictionary>
```

Creo que con esto os podéis hacer una idea de la potencia que tienen estos diccionarios personalizados pero como aún me quedan algunas cosas que contar que os pueden resultar interesantes he decidido hacer una segunda parte de este post donde hablaré de como compartir un diccionario entre proyectos y de como dar soporte a la edición de estos ficheros.

Evento en Mad.NUG

gsus — Tue, 23 Sep 2008 20:33:02 +0200

El jueves de la semana pasada participe como ponente en un evento de Mad.NUG y quería agradecer a todos los que fuisteis vuestra asistencia. La verdad es que a pesar de estar algo nervioso al principio creo que conseguí transmitir lo que pretendía. Del evento surgieron algunos temas que me gustaría comentar, pero no antes sin dejaros por aquí el enlace a la presentación que hice: Gestión del código fuente con Visual Studio Team System 2008

En primer lugar, uno de los comentarios que me hicieron fue que todo lo que enseñé estaba muy bien, pero que en el momento de tener que hacer una demostración a quien tiene la capacidad de decidir económicamente si se implanta el producto o no, harían falta entornos ya montados que pudiesen usarse. A pesar de que al final de la presentación comente qué había utilizado para realizar las demostraciones, no dije que el servidor de Team Foundation Server 2008 que utilice, es una máquina virtual que Microsoft tiene disponible para ser descargada en MSDN Download Center en la siguiente url: http://go.microsoft.com/?linkid=8048142

Esta máquina virtual esta montada sobre un Windows 2003 EE SP2 y viene con Visual Studio Team Suite 2008, Team Foundation Server 2008, Office 2007 SP1, Team Explorer 2008, Visual Studio 2005 y todos los prerequisitos de Team Foundation Server (SPS y SQL Server 2005). Además también esta disponible otra máquina virtual solo con Team Foundation Server 2008 y Team Explorer únicamente, ya que la anterior ocupa unos 5GB, lo cual puede resultar algo lento de descargar. Podéis descargar esta máquina virtual algo más reducida desde la siguiente url: http://go.microsoft.com/?linkid=8048143

Otra de las cosas que me comentaron fue como se podría afrontar una estrategia de Branching si uno de los proyectos fuese de tipo Web Application, que al hacer Branching y tener varias veces el mismo proyecto en un mismo equipo causaría problemas con los sitios Web o directorios virtuales de nuestro servidor IIS local. Tras indagar un poco y con la ayuda de Luis Fraile (vamos él ha sido quien ha dado con el comportamiento en estos casos) vimos que no hay ningún problema en este escenario. Al abrir el sitio web de un Branch, si el sitio Web ya existe en el IIS te da la opción de sobrescribir el contenido del mismo o de crear uno nuevo, pero como me parece un tema muy interesante voy a escribir una entrada en los próximos días al respecto, explicando de una forma más detallada el proceso.

En definitiva, muchas gracias a todos los asistentes por venir y por supuesto a Mad.NUG por dejarme compartir las cosas que voy aprendiendo sobre Team System.

Gestión del código fuente con VSTS 2008

gsus — Mon, 15 Sep 2008 21:52:00 +0200

Hacia ya bastante que no escribía nada por aquí, y muchos podréis pensar que me he pegado unas vacaciones de escándalo, pero ha sido justo lo contrario, no paro y tengo más cosas que hacer para los próximos meses que ya os iré contando. Cuando pase esta semana habré quitado de mi lista uno de los hitos importantes que es una sesión sobre la gestión del código fuente con Visual Studio Team System 2008 que voy a dar en el Grupo de Usuarios de .Net de Madrid (Mad.NUG).

El evento se celebrará este próximo Jueves día 18 a las 19:00h en la oficinas de Microsoft Ibérica en Madrid, pero para no replicar la información os remito directamente a la pagina del grupo de usuarios donde podréis encontrar la url de registro al evento y una pequeña descripción de los temas que trataré.

Gestión del código fuente con VSTS 2008

Espero veros por allí, pero si por algún motivo no podéis ir, no os preocupéis que se colgará la presentación y el material de las demos tanto aquí como en la página del grupo de usuarios.

Un saludo.

Añadir iconos de documentos en Team System Web Access

gsus — Sat, 19 Jul 2008 13:09:00 +0200

Probablemente la mayoría de vosotros ya conozcais Team System Web Access, pero para el que no lo conozca decirle que es frontal Web para Team Foundation Server que nos permite consultar, crear y modificar mucha información sin tener instalado ningún software en nuestro equipo. Esta especialmente pensado para los roles dentro de un equipo que no se dedican a escribir código o que no tienen porque usar Visual Studio como su herramienta de trabajo diario. En definitiva, una maravilla!

Pues bien, para los que ya lo hayáis usado, sabréis que una de las cosas que nos permite TSWA es acceder a la documentación que tengamos almacenada en nuestros Team Projects. Desde la pestaña de "Documents" podemos navegar por la estructura de directorios de nuestros documentos, subir nuevos ficheros o carpetas, la verdad es que va realmente bien, pero hay un pequeño detalle, que a pesar no ser nada funcional le quita "glamour" a esta herramienta.

Esta claro que el número de tipos de documentos diferentes que podemos almacenar aquí es infinito, podemos almacenar ficheros con la extensión que queremos. Por defecto en TSWA vienen iconos para 100 tipos de ficheros diferentes, Word, Excel, Pdf, Zip, Html, etc... Pero siempre habrá alguno que no se haya contemplado y como icono para ese tipo de documento aparecerá un feo logo de Windows. Sin ir más lejos las nuevas extensiones de documentos de Microsoft Office 2007 no están contempladas, así que si subimos un fichero con extensión ".docx" por ejemplo nos aparecerá ese icono genérico de extensión desconocida.

Añadir nuevos iconos de extensiones de ficheros en TSWA es extremadamente sencillo, pero no existe ningún opción desde la UI para hacerlo, así que tenemos que tocar a mano sobre la carpeta de instalación de TSWA.

Dentro de la carpeta de instalación de TSWA, normalmente "C:\Program Files\Microsoft Visual Studio 2008 Team System Web Access\" hay una estructura de directorios que contienen todos los ficheros del proyecto Web, la cache y algunas otras carpetas que no debemos tocar. La ruta que a nosotros nos interesa es la ruta donde se almacenan las imagenes de las extensiones de los ficheros que es: "Web\Resources\Images\Documents\FileIcons".

En esta carpeta encontramos un montón de ficheros .gif de 16x16 para cada una de las extensiones de ficheros de documentos que están contempladas en TSWA. Lo único que tenemos que hacer es poner aquí los ficheros con el icono para las extensiones desconocidas como ".docx".

El nombrado de los ficheros sigue el patrón "IC[Extension].GIF", por lo que para añadir la extensión ".docx" tendríamos que crear un fichero con el nombre "ICDOCX.GIF". Curiosamente dentro de la instalación de TSWA hay una carpeta donde existen casi 1000 imágenes de extensiones de ficheros y tenemos las imágenes para los ficheros de Office 2007. Solo tenemos que ir a la carpeta "Web\Resources\Images\FileExt", copiar de ahí los iconos que necesitemos, llevarlos a la carpeta de iconos de documentos y nombrarlos según el patrón que hemos descrito antes. Si no metemos la pata en ningún sitio el resultado debe ser este:

En definitiva, es un proceso muy sencillo, pero a la vez critico ya que tenemos que tocar a mano la carpeta de instalación de TSWA y cualquier descuido puede terminar en que tengamos que reinstalar la herramienta. Así que, ¡¡ tened cuidado con lo que tocáis !! :-D

Paquete de Check-In Policies: check-in policies pack v1.0

gsus — Wed, 16 Jul 2008 21:54:00 +0200

Una de las cosas que suele ocurrir normalmente en las implantaciones de Team Foundation Server es que se quieran activar una serie de políticas check-in que no vienen incluidas en el producto por lo que necesitamos distribuir estas políticas a cada una de las máquinas de los desarrolladores.

Dada la capacidad de extensibilidad de Team Foundation Server existe un gran numero de políticas de Check-In que han sido creadas por la comunidad. Muchas de estas políticas son realmente buenas y cada administrador de TFS se hace con una serie de ellas que hacen cumplir las necesidades de la compañía. A mi por ejemplo me gustan mucho la Code Comment CheckIn Policy (CCCP) de Christhop Wille, la de Get Latest Before Check-In de Steven Borg o la política de Source Analysis for C# de Eugene Zakhareyev.

Desgraciadamente estas políticas son de tres autores diferentes y aunque dos de ellas poseen un instalador, es un poco tedioso tener que distribuirlas por separado. La mejor opción al respecto sería crear un instalador de políticas que instale todas las políticas necesarias y nos permita hacerlo de forma cómoda o porque no, poder hacerlo dentro del protocolo de instalación de equipos de desarrollo que existe en muchas compañías.

Para ello lo que vamos a hacer es crear un paquete personalizado de Check-In Policies. Para crear el instalador voy a utilizar WiX (Windows Installer Xml) un framework opensource que permite generar ficheros de instalación MSI basándose en ficheros Xml. Además WiX es una de las nuevas características de Rosario, la próxima versión de Visual Studio. He intentado hacerlo utilizando la última CTP de Rosario, pero dado que es una máquina virtual e iba un poco lento, al final lo he hecho desde Visual Studio 2008 instalándome Votive, un paquete que permite la creación de proyectos de WiX desde esta versión de Visual Studio.

Dado que esto no pretende ser un tutorial de WiX voy a centrarme en el proceso necesario para desplegar una Check-In Policy a un equipo de desarrollo. En primer lugar, comentar que las políticas de Check-In son dlls resultantes de crear un proyecto de tipo Class Library y hacer que una clase herede de la clase PolicyBase incluida en el assembly Microsoft.TeamFoundation.VersionControl.Client. Esta clase PolicyBase implementa dos interfaces IPolicyDefinition e IPolicyEvaluation y por lo tanto nuestra clase también los debe implementar. Estos dos interfaces son usados dentro de la arquitectura de TFVC y permiten que se ejecute el código que se haya definido en las políticas creadas.

Una vez creada una política de Check-In son solo dos los pasos necesarios para integrarla dentro de Visual Studio y para que se pueda activar: Copiarla a una carpeta en el equipo de destino e introducir una clave en el registro de Windows en "HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation \SourceControl\Checkin Policies" que informe a Visual Studio de que existe una nueva política en la ruta donde se copió la dll.

Finalmente el paquete resultante contiene las siguiente políticas:

Power Tools 2008 Check-In Policies
- Changeset Comments Policy
- Custom Path Policy
- Forbidden Pattern Policy
- WorkItem Query Policy
Code Comment Checking Policy v3.0.0.1
Get Latest Before Check-in Policy
Source Analysis for C# Check-In Policy
Time That Task Check-In Policy
Merge / Branch Only Check-In Policy
Check for Comment Policy

Podéis descargar el archivo MSI de aquí y el código fuente de aquí

Referencias:

WiX Project
Votive (Necesario para abrir el código fuente desde VS2008)
WiX Wiki