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.

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

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)

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.

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”

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 !

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 !

Investigando sobre el mundo SharePoint me encontré con una guía para que los administradores configuren la co – autoría de su organización.
En ella explican cómo configurar las versiones, el período de creación de las mismas, el número máximo de autores y la posibilidad de deshabilitar la co- autoría.
A continuación les dejo un breve resumen y los links correspondientes, donde encontrarán detalladamente la configuración de cada uno de los puntos expuestos a continuación.

-Los autores pueden trabajar el mismo documento, y las ediciones se almacenarán en el servidor como versiones de documentos.
-Si se activa la versión, SharePoint Server toma instantáneas periódicas de los documentos, y los guarda para futuras consultas.
-Los administradores pueden limitar el número máximo de autores que pueden ser co-autores de un documento al mismo tiempo.
-Los co-autores también pueden ser deshabilitados por el cliente, utilizando la directiva del grupo.

Configure versioning for co-authoring
Configure the co-authoring versioning period
Configure the maximum number of co-authoring authors
Disable co-authoring

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 !

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

Hace unos días publiqué un post donde mencionaba los recaudos mínimos que deberíamos considerar al momento de instalar algún Add-on para TFS (vale también para VS).

Como no quiero que me consideren “apocalíptico” ni mucho menos trataré, por un lado, de mostrar las herramientas que nosotros hemos instalado y utilizado largamente y que nos han facilitado la vida en muchas oportunidades (o que estamos testeando con TFS 2010). Por el otro, me gustaría que ustedes comenten acerca de las experiencias que han tenido para que este post sirva, de alguna manera, como referencia de las herramientas que todo administrador o usuario de TFS debiera tener en su toolkit.

Empiezo yo:

Administración General

• Team Foundation Server Tools 2010: Un viejo conocido, en su versión para TFS 2010, que entre otras cosas incluye:
  • Alerts Explorer: UI gráfica que permite suscribirse a los diferentes eventos del servidor (cambio de un work-item, build terminado, nuevo check-in, etc.)
  • TFS Backups: administra un schedule para backups de la base de datos de configuración, de los proyectos de la colección, sharepoint (si se instaló con la integración de esa herramienta), reporting services (ídem)
  • Best Practices Analyzer: Verifica problemas de deploy, data usage, etc.
  • Pack de políticas de check-in
  • Mejoras para Team Explorer
  • Editor de Templates
• Team Foundation Sidekicks: Excelente herramienta de Attrice que permite visualizar/administrar entre otras cosas:
  • Historial de archivos del Source Control
  • Status (cheched out, locks, etc.)
  • Workspaces
  • Labels
  • Etc.

Seguridad

• Team Foundation Server Administration Tool: Uno de los problemas recurrentes al administrar proyectos de TFS es el de configurar permisos de usuarios. Hay que administrar seguridad tanto en el servidor TFS, el servidor de reportes y el sitio Sharepoint, cada uno con sus particularidades. Esta herramienta permitirá hacerlo todo junto desde un mismo lugar

Templates

• Microsoft Visual Studio Scrum 1.0: Uno de los templates más esperados.
• Scrum for Team System (antes conocido como Conchango): Excelente template Scrum, ahora en su versión para TFS 2010
• TMap for VS 2010: Un template para proceso de testing desarrollado por Sogeti en colaboración con MS

Visual Studio

• Productivity Power Tools (no es puramente TFS, pero los programadores –y otros- agradecidos) 
  • Solution Navigator: Permite ver clases (y sus miembros) desde el Solution Explorer, con filtros para visualizar solamente archivos abiertos, sin grabar, etc., vistas previas, y más.
  • Tab Well UI: Permite más posibilidades de manejo de ventanas del IDE para uso con múltiples monitores, tabs fijos (para que no desaparezcan cuando hay muchos documentos abiertos), coloreo de tabs según ciertas condiciones (soporta expresiones regulares), etc.
  • Searchable Add Reference Dialog: Ahora podemos hacer búsquedas al agregar referencias a nuestro proyecto !
  • Y mucho más …

Otros

• Team Foundation Server MSSCCI Provider 2010: Permite acceso al Version Control de TFS a herramientas que no soportan integración con Team Explorer, por ejemplo:
  • Visual Studio 2003
  • Visual Foxpro 9 SP2
  • Microsoft Access 2007
  • Powerbuilder 11.5
  • Enterprise Architect 7.5
  • y otros …
• VS Team Explorer Everywhere 2010: Permite acceso a TFS de cualquier IDE basada en Eclipse.

Creo que tengo alguna otra más para compartir, pero les dejo la posta a Uds. …

Saludos !

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Status on All Iterations Report

Stories Overview Report

Stories Progress Report

Información que proporciona el reporte

El reporte de Progreso de los Casos de Uso muestra el estado de realización determinado por las tareas definidas para implementar el mismo.

Este informe muestra para cada caso de uso, la siguiente información:

• Progreso (% completado): valor numérico que representa el porcentaje de trabajo completado.
• Horas completadas: representación visual de las horas completadas, que se muestra como una barra de color verde oscuro.
• Completado recientemente: representación visual de las horas completadas en el intervalo de tiempo especificado para Días recientes (calendario), que se muestra como una barra de color verde claro.
• Horas restantes: Horas restantes correspondientes a todas las tareas vinculadas al caso de uso o sus casos secundarios.

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

• Definir los casos de uso y las tareas, crear un vínculo Secundario de cada tarea al caso que implementa y crear un vínculo Secundario de las subtareas a su tarea primaria.
• Definir y actualizar los campos Completado y Restante para cada tarea o subtarea durante la iteración o el lanzamiento.
• Especificar las rutas de acceso de Iteración y Área para cada caso y tarea.

Análisis del reporte

El reporte permite visualizar el volumen de trabajo realizado por el equipo durante la última semana o un período de tiempo reciente. Se puede encontrar respuestas a las siguientes preguntas:

• ¿En qué casos el equipo progresó y cuáles están a punto de completarse?
• ¿En qué casos no ha trabajado el equipo?
• ¿A qué casos de uso les queda el mayor volumen de trabajo para completarse?
• ¿Hay trabajo bloqueado en algún caso?

  Los casos que no muestran una banda de color verde claro en la barra de progreso pueden indicar un problema de bloqueo.

• ¿Se puede entregar todo lo que se ha planeado? ¿Qué objetivos se deben suprimir y cuáles deben ser objeto de un cambio de ámbito?

Versión positiva del reporte

Un reporte positivo muestra que el equipo ha completado recientemente trabajo (color verde claro) en todos los casos que se espera estén en curso.

Versión negativa del reporte

Un reporte negativo podría mostrar una o más de los siguientes indicadores:

• No se muestra trabajo en uno o varios casos.

  Los casos con 0% de progreso o 0 horas restantes no tienen definido esfuerzo previsto ni tareas para ellos.

• Muchos casos de uso no tienen trabajo completado recientemente.

  Cuando varios casos indican ningún volumen o volúmenes muy pequeños de trabajo completado, el progreso del equipo es lento.

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Status on All Iterations Report

Hoy comentaremos sobre:

Stories Overview Report (Agile)

El siguiente reporte muestra gráficamente información general sobre los casos de uso definido para una iteración o área determinada.

Información que proporciona el reporte

El reporte presenta una visión del trabajo realizado para el conjunto de casos de uso filtrados hasta la fecha actual.

Este reporte muestra la siguiente información sobre cada caso de uso:

Progreso del trabajo

• % de horas completadas: un valor numérico y representación visual que muestra el porcentaje de trabajo completado.
• Horas restantes: un valor numérico de todas las horas restantes para todas las tareas vinculadas al caso de uso o sus casos secundarios.

Estado de la prueba

• Pruebas: un valor numérico que representa el número de casos de prueba vinculados al caso de uso o sus casos secundarios.
• Resultados de pruebas: un valor numérico y representación visual que muestra el porcentaje de casos de prueba, agrupados según el estado de su ejecución de pruebas más reciente, donde las opciones son Superadas (verde), Con error (rojo) o Sin ejecutar (negro).
• Errores: un valor numérico y representación visual que muestra el número de errores vinculados al caso de prueba o caso de uso, donde las opciones son Activa (azul) y Resuelto (oro).

El reporte de Información general enumera y resalta los casos según los siguientes criterios:

• Los casos aparecen por orden de importancia, que está basado en su clasificación asignada.
• Los casos aparecen en tipo en negrita cuando están en el estado activo o resuelto.
• Los casos aparecen en tipo normal cuando están en el estado cerrado.
• Los casos aparecen en tipo gris cuando su iteración o área asignada está fuera del conjunto filtrado, pero tienen tareas o casos secundarios que están dentro del conjunto filtrado de iteraciones o áreas de producto.

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

• Definir los casos de uso y tareas, crear un vínculo Secundario desde cada tarea a un caso de uso y crear un vínculo Secundario desde cualquier subtarea a su tarea primaria.
• Definir y actualizar los campos Completado y Restante para cada tarea o subtarea durante la iteración o versión.
• Definir los casos de prueba y crear el vínculo Prueba realiza por desde cada caso de prueba a un caso de uso.
• Para cada error, crear el vínculo Prueba realiza por al caso de prueba que identificó el defecto de código o un vínculo Relacionado al caso de uso con el que está relacionado el error.
• Establecer el Estado de cada error en Resuelto cuando se corrija.
• Especificar las rutas de acceso Área e Iteración para cada caso, tarea, caso de prueba y error.

Análisis del reporte

El reporte de Información general muestra el progreso de trabajo global en tres áreas que son importantes para completar y cerrar un caso de uso:

• Tareas implementadas para completar el caso de uso.
• Casos de prueba ejecutados para asegurar la calidad de los casos implementados.
• Errores identificados que indican los problemas con la calidad de los casos de uso.

Progreso del trabajo

• ¿Corresponde a sus expectativas la cantidad de trabajo que resta para cada caso de uso?
• ¿Se implementan primero los casos de uso clasificados según su relevancia?
• ¿Cuántas pruebas se definen para cada caso de uso?¿Cuántas pruebas se superan?
• ¿Qué casos de uso se implementan que no tienen ningún caso de prueba definido para ellos?

Progreso de la calidad

• ¿Cuántos casos de prueba se han ejecutado para cada caso de uso y cuántos han superado las pruebas?
• ¿Cuántos errores activos tiene cada caso de uso?
• ¿Se encuentran errores para los casos de uso que se prueban?
• ¿Se resuelven los errores o siguen activos?

Evaluación de riesgo

• ¿Qué casos de uso están en riesgo?
• ¿Qué casos de uso no son suficientemente estables para la versión?
• ¿Qué casos de uso puede distribuir hoy el equipo?

Versión positiva del reporte

Un reporte positivo muestra más progreso en los casos de uso que aparecen cerca de la parte superior del reporte. En la imagen que se muestra a continuación se visualiza que el equipo ha realizado más trabajo para los casos que aparecen en el reporte.

Versión negativa del reporte

Un reporte negativo muestra una o más de los siguientes indicadores:

• El equipo está realizando más progreso en los casos de uso que tienen un rango inferior que en los que tienen un rango superior.
• Hay más pruebas con errores que superadas.
• Se producen errores en las pruebas para un caso de uso, pero no se crea ningún elemento de trabajo de error.

Hasta la próxima.

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Hoy nos toca comentar un nuevo reporte.

Status on All Iterations Report

Este reporte permite realizar un seguimiento del rendimiento del equipo sobre las iteraciones en las que ha participado.

Información que proporciona el reporte

El reporte de estado muestra para cada iteración especificada la siguiente información:

• Casos de Uso cerrados: número de casos de uso que se han cerrado.
• Progreso (Horas): representación visual y numérica en dos barras que representa los valores para Estimación original (gris), Completado (verde) y Restante (azul claro) basados en el número acumulado de horas que se definen para todas las tareas.
• Errores: valor numérico y representación visual para todos los errores, agrupados por sus estados actuales de Activo (azul), Resuelto (oro) y Cerrado (verde).Estos valores se derivan de los valores actuales que se especifican durante la iteración y el estado de cada error.

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

• Definir casos de uso, tareas y errores y especificar las rutas de acceso de Área e Iteración para cada uno.
• Especificar los campos Estimación original, Completado y Restante para cada tarea o subtarea y actualizar los campos Completado y Restante durante la iteración.
• Actualizar el Estado de cada artículo, tarea y error cuando progrese de estado activo a cerrado.

Análisis del reporte

El reporte permite determinar cuántos casos de uso están listos para la versión comercial y comprender mejor la tasa de progreso del equipo. El reporte permite encontrar respuestas a las siguientes preguntas:

• ¿Coincidió el ámbito de trabajo para cada iteración con la capacidad del equipo?
• ¿El número de casos de uso cerrados son los esperados por iteración?
• ¿Está el equipo resolviendo y cerrando más errores?
• ¿Cuántos casos de uso puede distribuir el equipo?

Versión positiva del reporte

En un reporte de estado de iteraciones positivo muestra un progreso de horas a medida que transcurren iteraciones.

Versión negativa del reporte

Un reporte de estado negativo podría mostrar uno o más de los siguientes indicadores:

• No se cerró ningún caso de uso en una o más iteraciones.
• El número de horas estimadas y completadas varía ampliamente dentro de las iteraciones o entre ellas.
• El número de errores encontrados no aumenta con cada iteración sucesiva.

   

Hasta la próxima.