Autor: gsus

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

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?

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

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.

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.

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?

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.

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?

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.

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?

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?

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?

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.

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?

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€

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?

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.

• Building Quality Code with VSTS 2008 Development Edition (Part 1: Managed Code)
• Building Quality Code with VSTS 2008 Development Edition (Part 2: Native Code)
• Introduction to Database Development with VSTS 2008 Database Edition
• Managing your Team Development Efforts with Team System 2008
• Version Control and Integration with Team System 2008

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.

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?

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.

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?

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.

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?