Referencia: Eligiendo Process Template en TFS 2012

por Victor Passador  17. diciembre 2012

Al momento de crear un Team Project, siempre surgen dudas acerca de los estados que toma cada uno de los diferentes tipos de Work Item, dependiendo del Template Process que se elija. Por eso está bueno tener a mano este tipo de links:

Choose a Process Template

Un buen resumen en forma de tabla para tener de referencia.

Hasta la próxima!

Tags:

TFS

Agregando Bugs al Board de Web Access - Template MSF for Agile 5.0

por Victor Passador  17. diciembre 2012

TFS 2012 propone gestionar las tareas del desarrollo a través de un Web Access totalmente renovado desde su versión 2010. Utilizando esta herramienta, el PM podrá entre otras cosas, administrar las capacidades del equipo, crear y asignar User Stories, Taks, Bugs, planificar sprints, verificar estado de avance del proyecto a través del Burndown chart, del reporte de salud de los Builds, y varios etcéteras más.

La planificación propiamente dicha, se realiza a través del “Board” (un tablero muy útil en daily meetings además de otros momentos) y facilita la administración de tareas ya que no hay que trasladar el cambio de estado de los papelitos en el “tablero de corcho” a la herramienta, sino que se puede hacer directamente desde ésta.

Considero que la herramienta aporta mucho a la agilidad, pero en ciertos escenarios, se queda corta en posibilidades de personalización.

El caso que quiero plantear se da con un Team Project ya creado y migrado desde la versión anterior, con el template MSF for Agile 5.0, donde quisiéramos que aparezcan en ese board los bugs, además de las tareas.

Aquí se explica cómo es que funciona el board y cuáles son los tipos de Work Item que allí aparecen.

Si bien el texto es claro y con ejemplos, no cubre el 100% de la necesidad de nuestro escenario. Describiré más abajo cuáles son los pasos a seguir (tomando los pasos detallados en el link y ampliando con lo que estaba faltando):


Aclaración 1: Cada uno de estos pasos consiste en exportar desde TFS a un directorio local una sección del Process Template con el que fue creado el Team Project, modificar las entradas que sean necesarias y volver a incorporar esa sección modificada en el servidor, todo esto utilizando el comando witadmin

Aclaración 2: Como estamos modificando definiciones en un servidor que probablemente esté en producción, es buena práctica conservar una copia de cada archivo que obtengamos luego de ejecutar un comando “witadmin exportxxx …”. Si las cosas no salen como esperamos, teniendo un backup, siempre será posible volver todo a su estado inicial ejecutando el comando “witadmin importxxx …”


Paso 1: “Bajar” la definición de categorías del template para poder incluir a los bugs dentro de la categoría Task Category (hace un tiempo escribí aquí sobre categorías de Work Items)

witadmin exportcategories
     /collection:CollectionURL
     /p:ProjectName
     /f:"DirectoryPath\categories.xml"

Paso 2: Modificar la sección correspondiente para que quede como se muestra a continuación

<CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
   <DEFAULTWORKITEMTYPE name="Task" />
   <WORKITEMTYPE name="Bug" />
</CATEGORY>

Paso 3: “Subir” la nueva definición

witadmin importcategories
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\categories.xml"

Paso 4: “Bajar” la definición de configuración para agregar los estados (metastates) y así unificar entre Task y Bugs

witadmin exportcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"

Paso 5: Modificar la sección correspondiente para que quede como se muestra a continuación

<TaskWorkItems category="Microsoft.TaskCategory">
    <States>
       <State value="Active" type="Proposed"/>
        <State value="Resolved" type="InProgress"/>
        <State value="Closed" type="Complete"/>
    </States>
</TaskWorkItems>

Paso 6: “Subir” la nueva definición

witadmin importcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"


Atención: En el ejemplo del artículo de MSDN hay una entrada para el estado “New”, pero debemos eliminarla porque no existe ese estado en el template MSF for Agile 5.0.  Si omitimos ese cambio, obtendremos un error al ejecutar el comando witadmin importcommonprocessconfig


Paso 7: “Bajar” la definición de Bug para poder modificar el template y agregar el campo Activity

witadmin exportwitd
    /collection:CollectionURL
    /p:ProjectName
    /n:Bug
    /f:"DirectoryPath\Bug.xml"

Paso 8: Modificar la sección correspondiente para que quede como se muestra a continuación

<FIELD name="Activity" reportable="dimension" type="String" refname="Microsoft.VSTS.Common.Activity">
    <HELPTEXT>Type of work involved</HELPTEXT>
    <SUGGESTEDVALUES expanditems="true">
        <LISTITEM value="Development"/>
        <LISTITEM value="Requirements"/>
        <LISTITEM value="Design"/>
        <LISTITEM value="Testing"/>
        <LISTITEM value="Deployment"/>
        <LISTITEM value="Documentation"/>
    </SUGGESTEDVALUES>
</FIELD>

Paso 9: “Subir” la nueva definición

witadmin importwitd
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\Bug.xml"


Aclaración: Si bien estamos agregando este campo a la definición del bug porque el bug ahora pertenece a la categoría TaskCategory (paso 1) y requiere de esta definición, no es necesario modificar el Layout de edición a menos que queramos tener acceso a ese campo al momento de editar un bug.


Conclusión

Como ven en la captura, ahora tenemos visibilidad de los Bugs en el board Agile, y además, se ve una nueva columna (Resolved) que muestra los bugs en ese estado. Por favor no tomen en cuenta el Burndown Chart, es sólo un proyecto para pruebas Smile

image
 
Si después de realizar todo el proceso, los bugs siguen sin aparecer, por favor revisen que estén vinculados a la respectiva User Story.

Hasta la próxima!

Tags: , ,

ALM | Gestión de Proyectos | TFS

Experiencias: Moviendo Project Collections de TFS 2010 a una nueva instalación

por Victor Passador  1. octubre 2012

Uno de nuestros clientes tenía una implementación de TFS 2010 montada sobre Windows 2003 que había venido migrándose desde TFS 2005. Si bien el servidor estaba funcionando perfectamente, la compra de un nuevo hardware mucho más potente sirvió como excusa para plantear una nueva instalación, desde cero, pero ya en una plataforma mucho más moderna, y de 64 bits.

“Teniendo Project Collections la migración será mucho más sencilla …” dijimos. Si bien no estábamos mintiendo, sabíamos que no estábamos contando la versión completa de la historia, pero apostábamos a que no iba a haber mayores dificultades y así fue.

Como corresponde en estos casos, sin siquiera pensar en conectarnos a cualquiera de los servidores, empezamos a armar la checklist (fundamental!), que en versión resumida aquí les transcribo:

En el servidor de origen

1) Detener y separar la project collection: En este paso podemos dejar un mensaje para advertir a los usuarios que intenten conectarse mientras dure el proceso.

Paso 1

2) Hacer un backup de la base de datos en SQL Server (recordar que cada project collection tiene su propia BBDD)

3) Hacer un backup de la Sharepoint Site Collection: Aquí un ejemplo vía línea de comandos

 1: stsadm -o backup -url http://contoso/sites/DefaultCollection -filename c:\default_collection.bak

4) Hacer un backup de los Reportes (Reporting Services): Si utilizamos Reporting Services, esta tarea puede resultar realmente tediosa ya que hay que copiar uno por uno. Dependiendo del template utilizado para crear los proyectos, y obviamente la cantidad de proyectos, esto nos puede llevar mucho tiempo. Por suerte Aaron Block publicó unos scripts (VB) que realizan la tarea escribiendo sólo una línea!. Eso si, debemos editar el script para colocar la report folder de nuestro servidor en este script.

En el servidor de destino

1) Restaurar la base de datos

2) Restaurar la Sharepoint Site Collection

 1: stsadm -o restore -url http://contoso/sites/DefaultCollection -filename c:\default_collection.bak 

3) Restarurar los Reportes

Aquí nuevamente utilizaremos los scripts de Aaron Block editando la report folder de destino según corresponda. Para este paso usaremos este script.

4) Adjuntar (attach) la Project Collection utilizando la consola de administración de TFS

5) Modificar la ubicación del Default Site de Sharepoint, también desde la consola

image

6) Reparar la conexión a Sharepoint

7) Por cada proyecto de la colección, apuntar a la nueva dirección del Project Portal y de la Process Guidance. Esto se logra desde Visual Studio –> Team Explorer –> Proyecto –> Team Project Settings –> Portal Settings

Como verán, si bien no es un ejercicio de un sólo paso, contando con una buena checklist no es una tarea imposible.

Hasta la próxima!

GetReportsFromServer.rss (5,12 kb)

PushReportsToServer.rss (8,80 kb)

Tags: ,

TFS

Testing unitario y TDD con Visual Studio 2010

por Victor Passador  4. agosto 2011

“Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.” ExtremeProgramming.org

 

Un poco de contexto

Como generalmente sucede en todos los ámbitos, una de las cosas más difíciles de conseguir es el equilibrio, y la creación de Tests Unitarios no queda fuera de esta premisa.

Por un lado es imposible negar los beneficios que aporta contar con pruebas automatizadas, pero por otro lado también se hace difícil contradecir a aquellos que argumentan que es muy costoso su mantenimiento ante cambios en los requerimientos.

No es la idea de este post entrar en un debate interminable defendiendo una postura u otra, sólo me limitaré a decir que no somos fanáticos de los extremos y que si bien consideramos que es indispensable contar con un buen set de pruebas unitarias, tampoco perdemos de vista el costo de su mantenimiento y vamos adaptando el modelo según las necesidades y posibilidades.

Antes de ir directamente a la herramienta, repasemos algunas definiciones.

 

El ABC de las pruebas unitarias

Toda prueba unitaria que se precie de tal, deberá contar sí o sí con las siguientes características:

  • Ejecución rápida
  • Ambito limitado
  • Automatizable y repetible
  • Cualquiera puede ejecutarlo
  • Independiente
  • Alta cobertura de código

 

El ABC del TDD

En el Desarrollo Guiado por Pruebas (Test-Driven Development – TDD) se dice que no existe ningún motivo para escribir código salvo alguna prueba que esté fallando. Esto obliga (a modo de resumen) a trabajar con un ciclo de vida que incluye los siguientes pasos:

  • Ante cada nuevo requerimiento, escribir un test. El test inevitablemente fallará porque no hay código que implemente ese requerimiento todavía.
  • Escribir el código que pase el test. Se deben enfocar los recursos a que el test pase, sin preocuparse por cuestiones “superfluas” (.. del tipo “ya que estamos, agrego una sobrecarga que reciba tal parámetro porque probablemente lo necesite más adelante”). Tampoco por la elegancia del código. El único objetivo es que el test pase.
  • Refactorizar: Es aquí donde se modifca el código para mejorar cuestiones como mantenibilidad, limpieza de código duplicado, etc., sin afectar obviamente la funcionalidad. Esto se comprueba corriendo sucesivamente las pruebas (aquí se ve el beneficio de pruebas que se puedan ejecutar en poco tiempo).

 

Entrando ahora sí de lleno en la herramienta, veamos qué nos aporta en este sentido.

 

Ayudas en la edición de código

Como soporte a la práctica de TDD, Visual Studio 2010 cuenta con algunas funcionalidades orientadas a la mejora en la productividad en este ámbito:

Code Snippets: permiten rápidamente generar clases de test (“testc”) o métodos de test (“testm”)

imageimage

Al escribirse primero las pruebas, obviamente fallaran las referencias a las clases a testear, pero con la generaci��n automática de código, se facilita la tarea de crear el esqueleto de esas clases:

image

image

Intellisense en modo Suggestion: En el modo al que estábamos acostumbrados a usar Intellisense (modo Completion), era fácil agregar una referencia a un tipo o variable existente, pero esto no es muy “TDD Friendly”. En VS2010 existe también el modo Suggestion (se activa con Ctrl+Alt+Space) que muestra, mientras estamos tipiando, un cuadro de texto sobre la lista de tipos sugeridos sin obligarnos a seleccionar ninguno.

image

Ejecución de pruebas unitarias

En cuanto a la ejecución de las pruebas unitarias, más allá de nuestro objetivo de ver muchos iconitos verdes, una de las metas buscadas es conseguir una alta cobertura de código. De nada sirve tener toda una batería de pruebas unitarias si estamos cubriendo (probando) menos de la mitad del código escrito.

La cobertura de código (Code Coverage) es una métrica importantísima que deberíamos obtener para poder certificar que nuestros casos de prueba están cubriendo la totalidad (o la mayor parte posible) del código de la aplicación.

Para habilitar los reportes de Code Coverage en VS2010 tenemos que modificar el archivo “Local.testsettings” y dentro de la opción “Data and Diagnostics” marcar el check correspondiente a “Code Coverage”

CodeCoverageSettings

Una vez ejecutadas las pruebas, en la ventana Code Coverage Results, podremos ver los porcentajes de ese indicador y a su vez, en el editor de código, ver resaltadas las líneas afectadas por la prueba.

CodeCoverageResults

Posts anteriores de esta serie:

Para ir calentando motores …

Contribuyendo a la mejora de calidad de software

Algunas referencias más:

http://geeks.ms/blogs/adiazmartin/archive/2010/01/12/m-225-s-r-225-pido-con-visual-studio-2010-intellisense-para-tdd.aspx

http://blogs.msdn.com/b/ukvsts/archive/2010/03/17/test-driven-development-with-visual-studio-2010.aspx

 

Hasta la próxima!

Tags: , ,

Testing | Visual Studio | ALM

Testing con VSTS 2010–Contribuyendo a la mejora de calidad de software

por Victor Passador  19. abril 2011

Como habíamos prometido, daremos inicio con este post a la serie de publicaciones con las que intentaremos mostrar de qué manera se puede incrementar la calidad del software que nuestra empresa produce, mejorando el proceso de testing en las diferentes formas que toma a lo largo del ciclo de vida de la aplicación.

Tipos de testing vs. herramientas de testing

En las primeras etapas del ciclo de vida de la aplicación, en aquellas donde se comienzan a implementar mayormente requerimientos no funcionales (APIs, frameworks, etc.), se requiere de un tipo de tester especializado, con altos conocimientos de programación, que genere casos de pruebas unitarias con un alto grado de automatización (cuando digo alto apunto al 100% de automatización)

A medida que las iteraciones avanzan y se empiezan a obtener las primeras piezas funcionales, aparece la necesidad de un testing totalmente diferente, opuesto, donde el tester necesita altos conocimientos del proceso de negocio y pocos o nulos conocimientos de programación.

Si trazáramos una línea, podríamos decir entonces que tenemos en una punta un testing de tipo “especializado”, con mayoría de casos de test automatizados construidos por expertos en programación, y en la otra punta un testing más “generalista” con gran cantidad de casos de test manuales a cargo de especialistas en el negocio en cuestión, con toda una escala de grises en el medio.

Generalista vs. Especialista 001

Según algunos estudios, se indica que la mayoría de las herramientas de apoyo al testing apuntan a la parte “especialista”, siendo que el grueso del esfuerzo que realiza la empresa se ubica en la parte “generalista”

Generalista vs. Especialista 002

VSTS 2010 como solución ALM ante la problemática del testing

Con este enfoque como guía, iremos mostrando en sucesivas entregas, de qué manera VSTS 2010 contribuye a la mejora del proceso de testing en todo el espectro.

Comenzaremos mostrando las herramientas que propone la solución de MS desde el extremo más especialista, hasta llegar al punto opuesto, abarcando los siguientes tópicos:

  • Testing unitario y las mejoras para aplicación de técnicas de TDD (Test Driven Development)
  • Intellitrace
  • Coded UI Test
  • Lab Management
  • Integración Continua

 

Hasta la próxima !

Tags: , , ,

ALM | TFS | Testing | Visual Studio

TFSJobAgent dejó de funcionar luego de la instalación del SP1 de TFS 2010

por Victor Passador  5. abril 2011

En uno de los servidores con los que estamos trabajando, tuvimos problemas luego de la instalación del Service Pack 1 de Team Foundation Server 2010.

Era uno de esos servidores prolijitos, instalados desde cero, nada de migraciones raras ni parches extraños.

Luego de una instalación exitosa del SP1, los servicios parecían funcionar bien pero la Project Collection empezó dar error de acceso y se empezaron a encolar tareas sin pudieran completarse (ver Consola de Administración de TFS –> Team Project Collections –> Solapa “Status”).

Después de investigar un buen rato, resultó que uno de los nuevos servicios que trae la versión 2010 conocido como TFSJobAgent no podía iniciar por un problema de logon (primer indicio, alguien recordó que el usuario con el que se instalaron el SP1 había cambiado su password luego de la instalación inicial del servidor pero antes de la instalación del SP1).

Sabiendo esto, actualizamos las credenciales de las cuentas desde la misma consola pero el servicio seguía sin levantar. Por otra parte, ¿donde está ese servicio?. Si no hubiera leído esto no hubiera sabido que el nombre real es “Visual Studio Team Foundation Background Job Agent”. En algún momento tuvimos la necesidad de detenerlo, pero lo hicimos usando el comando “net stop tfsjobagent”.

Cambiando las credenciales con las que se inicia ese servicio por las nuevas, todo volvió a funcionar con debía. Por algún motivo, no se habían actualizado justo en ese punto.

Saludos !

Tags: ,

TFS

Receta mágica de ALM para aplicar en TFS

por Victor Passador  26. marzo 2011

En la búsqueda diaria de la solución absoluta y definitiva a los problemas de gestión del código fuente, di con un post de El Bruno donde plantea algo muy simple pero efectivo:

1. Formación

    1.1 Conocer las capacidades de la herramienta

    1.2 Conocer la problemática del negocio

2. Tomar una decisión para comenzar a trabajar

3. Cada 6 semanas/meses ajustar la forma de trabajo

4. Goto 2

 

Según El Bruno, esto surge como conclusión de una Mesa Redonda con la gente de MadridDotNet donde se compartieron experiencias de administración de código fuente en cuestiones de branching, merge, archivos históricos, la maldición del checkout exclusivo y otras cuestiones.

Recomiendo su lectura, es un post cortito y ameno.

Hasta la próxima !

Tags: ,

Gestión de Proyectos | ALM

Visual Studio 2010 and .NET Framework 4 Training Kit

por Victor Passador  26. marzo 2011

Ya van quedando cada vez menos excusas para no estar entrenado con lo último. Acaba de salir publicado un Training Kit gratuito para VS 2010 y .NET 4.0.

Es un download de un poco más de 400MB que en disco se transforman en casi 2GB de presentaciones, papers, hand-on-labs, código de ejemplo, etc.

Pueden descargarlo desde aquí.

Enjoy !

Tags: ,

.NET | Visual Studio

Testing con VSTS 2010 – Para ir calentando motores …

por Victor Passador  18. febrero 2011

Estamos preparando una serie de post dedicados a testing con VSTS 2010 en las diferentes variantes en que se presenta a lo largo del ciclo de vida de la aplicación, y para ir introduciendo el tema quisiera dejarles unos links para que tengan a mano.

Se trata del blog de Mathew Aniyan, PM de Microsoft. En su blog, Mathew ha estado publicando una serie de Tips relacionado a lo que se conoce como Coded UI Test (Pruebas programáticas de Interfaz de Usuario).

Al momento de publicar este post, llegó hasta el N° 8, posteado con fecha enero/2010. Esperamos que retome la iniciativa y siga publicando más trucos.

Pueden ver la serie de tips aquí.

Saludos !

Tags: , , ,

ALM | TFS | Visual Studio | Testing

TFS 2010–”The server returned content type text/html, which is not supported” al hacer Get Latest Version

por Victor Passador  20. enero 2011

En realidad este error lo obtuvimos inicialmente al intentar encolar una build en un proyecto recientemente “trasplantado” desde otro servidor. Obviamente en el servidor de origen no había problemas.

Como era muy escasa la información registrada en los diferentes logs, investigamos un poco y nos dimos cuenta que el error ocurría cuando el build server intentaba descargar la propia definición del build (basada en el DefaultTemplate.xml) para hacer su trabajo. Podíamos obtener ese mismo error desde Visual Studio intentando descargar cualquier otro template de la carpeta BuildProcessTemplates del Source Control.

Sabiendo que no era un tema del build server sino algo más genérico, volvimos a buscar y apareció la solución. Hay que seguir estos pasos:

  • Detener IIS
  • Borrar la caché local del servidor TFS (buscar en C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\_tfs_data)
  • Reiniciar IIS

 

Voilà !!

Hasta la próxima !!

Tags: , , ,

ALM | TFS | Visual Studio | Build Automation

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML