Luis Fraile

Muchos conocéis mi gusto por personalizar y extender Team Foundation Server, uno de estos puntos de extensibilidad es la creación de custom controls para los Work Items.

Esto es algo “relativamente” sencillo cuando sólo lo queremos hacer para el interfaz de Team Explorer. Sin embargo es bastante complejo a la hora de hacerlo para el interfaz de acceso web a TFS.

Y si a esto unimos que al SDK disponible hasta este momento le faltaban unos ficheros, pues nos hace la vida más dificil aún.

Pero este fallo ya le han reparado y se han publicado esos ficheros que faltan, y aquí los tenéis:

• Ficheros que faltan en el proyecto de ejemplo

Post original: http://blogs.msdn.com/hakane/archive/2009/02/13/fix-work-item-custom-controls-sdk-for-web-access.aspx

Hola a todos, veo en el blog del ex-MVP (ahora trabaja en Microsoft), Grant Hollyday, que ha creado un paquete de informes para  poder comprobar que los servidores están funcionando correctamente e identificar posibles cuellos de botella y solucionarlos. Decir, que el TFS del que se encarga tiene (sacado de su blog) 3500 usuarios activos y 10.000.000 (si, no sobra ningún 0) de peticiones de código fuente y work items al día.

Como podéis imaginar, gestionar un servidor así, no es sencillo, y por eso crearon estos informes, para poder gestionar esto.

Y ahora los ponen a nuestra disposición: TFS Performance Report Pack.zip (~250kb)

Bueno voy a hacer una traducción/resumen de lo que pone Grant en su blog, para los que no  leáis la lengua de Shakespeare.

Los requerimientos, que también podéis ver en su blog son:

• SQL Server Reporting Services 2008*
• Un usuario con permisos de lectura en la base de datos del servidor TfsActivityLogging.
• Una fuente de datos compartida para usar con el informe
• Habilitar el log de TFS, esto ya es el comportamiento por defecto de TFS 2008.
  • En TFS 2005hay que habilitar el indicador “commandLogging” en el web.config general de TFS, también dice que la consulta del informe puede tener que hacer cambios.

Grant comenta en el blog que, técnicamente no hay necesidad de SQL Server 2008, pero bueno, al igual que el, yo os recomiendo que vayáis migrando, puesto que lo necesitaréis para TFS 2010.

Instalación

El zip contiene los ficheros *.rdl de definición de los informes, que están diseñados para ser instalados en el servidor de reporting de nuestro TFS.

Para instalarlos, y estando logados con una cuenta con permisos de administrador en TFS:

1. Abrimos el navegador de internet y entramos a /Reports">http://<servidor>/Reports
2. Creamos un nuevo directorio que se llame “Estado servidor”.
3. Creamos una nueva fuente de datos compartida llamada “TfsActivityReportDS”, y ponemos la siguiente cadena de conexión:
1. Data Source=localhost;Initial Catalog=TfsActivityLogging
2. En las credenciales pondremos un usuario que tenga acceso a la base de datos de TfsActivityLogging del TFS.
3. Seleccionamos que use creedenciales de Windows para conectar.

Los informes incluidos son:

Tiempos de ejecución

Este informe muestra el tiempo de ejecución por comando y por usuario, ayudándonos a comprobar, que comandos son los que sobrecargan más al servidor por un lado, y que usuarios/herramientas son los que más carga crean en el sevidor

Estado del servidor – cola de peticiones a Source Control

Como bien dice Grant, el control de código fuente es, con diferencia, la aplicación que más recursos consume del servidor.

A lo largo del día, las peticiones se van encolando para ser procesadas como transacciones a la base de datos, con este informe, podermos ver si tenemos alguna petición causándonos un cuello de botella, y cuál es el estado actual de la cola de transacciones.

Si vemos mucho “rojo” significa que tenemos operaciones muy largas ejecutándose y que podemos tener problemas.

Estado del servidor – los usuarios “top” que se saltan el proxy

Para obtener una mayor calidad de servicio, cuando tenemos muchos usuarios accediendo al TFs y haciendo muchas peticiones de Version Control, es muy recomendable instalar proxies de TFS, que incluso los podemos poner mediante un cluster de balanceo de carga, liberando así carga del servidor.

Con este informe, la gente de IT, puede descubrir que usuarios están accediendo  directamente al servidor TFS, sin pasar por servidores Proxy, para que puedan mejorar la calidad de servicio configurando esos usuarios para que usen proxy.

Estado del servidor – históricos de rendimiento

Este informe nos muestra un resumen de los tiempos medios de respuesta históricos tanto del sistema de Work Items, como de Version Control.

Aquí podemos ver, de media, cuanto tienen que esperar los usuarios para procesar sus peticiones, y que días de la semana son los más críticos a nivel de rendimiento.

Estado del servidor – rendimiento reciente

Este informe es similar al anterior pero con más nivel de granularidad sobre el rendimiento del servidor.

Empieza con una vista del tiempo medio de respuesta del servidor a nivel general, y posteriormente nos muestra la información relativa a las descargas de ficheros de Version Control y el tiempo medio de respuesta para el mismo periodo.

Con este informe podemos ver la relación entre el rendimiento degradado del servidor y el tiempo medio de respuesta de los dos subsistemas (WI y VC).

Como afecta un número grande de descargas al rendimiento general del servidor, y la “salud” general del servidor.

 

Bueno espero que esta información os haya sido tan útil como a mí, aquí os dejo de nuevo el link al post de Grant, y si queréis por aquí me tenéis también para cualquier aclaración:

http://blogs.msdn.com/granth/archive/2009/02/03/announcing-tfs-performance-report-pack.aspx

Que no existen balas de plata metodológicas es algo que ya hemos dicho muchas veces y que seguro que sabemos todos.

Y por tanto, no hay una metodología para controlarlas a todas, cada equipo, cada proyecto, cada entorno es distinto e intransferible, y lo que vale para uno no vale para otros, por tanto es de vital importancia entender cómo funcionamos, tanto como equipo, como cada miembro individual, para poder aplicar lo que funciona y lo que no.

Lo cierto es que supongo que no estoy contando nada nuevo, es algo que siempre se habla, y que últimamente, Ivar Jacobson nos ha recordado tanto en aquel evento de ALM del año pasado en Madrid, como en otra ocasión que tuve de estar hablando con el despues del TechEd en Barcelona.

Y es que, en gran medida estoy de acuerdo con su mensaje, al final, una de las cosas más importantes a la hora de poner orden, es aplicar las prácticas que funcionan en la que sea nuestra situación actual.

Hay muchas prácticas definidas en otras tantas metodologías, desde Test Driven Development, programación por parejas, desarrollo iterativo (aunque esta es omnipresente), casos de uso, retrospectivas, etc., etc., que podemos aplicar, aunque no apliquemos la metodología en cuestión.

Con esto no se quiere decir que no se aplique con rigor una metodología, y que simplemente apliquemos prácticas, nada más lejos de la realidad. Es muy importante, sobre todo al principio, que tengamos algo en lo que apoyarnos y que guíe nuestros pasos.

Siempre es indispensable contar con una buena metodología, escogida según nuestras necesidades, que forme la base de nuestra gestión. Lo que quiero decir con esto, es que, basándonos en nuestra experiencia, debemos evolucionar nuestro proceso, adoptando prácticas que observemos y veamos válidas, aunque no formen parte de nuestra metodología, y descartar prácticas que nos creen impedimentos o aporten lo suficiente.

Pero ojo al añadir o eliminar prácticas (especialmente al eliminar), no todas las prácticas aportan beneficios inmediatos, y debemos ser muy conscientes de todo el proceso, no sólo de la situación inmediata, como decía Ivar, “Be Smart”. Cuando nos planteemos el quitar o añadir, debemos tener razones de peso, observadas durante un tiempo y compartidas con el equipo.

Y por eso agrego aquí a Scrum, ya que es probablemente la más “ligera” de las metodologías, las prácticas que específica son relativamente pocas y fáciles de seguir, pero hay una que encaja a la perfección con esto que aquí escribo, y son las reuniones de retrospectiva del sprint. En estas reuniones siempre detallaremos que es lo que hemos hecho bien, lo que hemos hecho mal, lo que hemos aprendido, y lo que no es necesario. En definitiva, la observación de todas nuestras prácticas para evolucionar el proceso.

Esta es una de las grandes cosas de Scrum, el tratar el proceso en si mismo como algo vivo, y no sólo como algo vivo, si no como algo que se puede cambiar con relativa facilidad (todos sabemos que no todo es tan fácil como parece), y con frecuencia.

Al final, en el proceso de desarrollo, dependemos de las personas y de como funcionan, y esto es lo que debemos observar para poder tener un proceso consistente, y, aunque en esto difiero con Ivar, yo si considero que el proceso de desarrollo es un 80% de pensar, y un 20% de aplicar patrones y/o prácticas (justo al contrario que Ivar), ya que por muy detallados que sean esos patrones, y esas prácticas, debemos de aplicar nuestro conocimiento y pensamiento para aplicarlas a nuestros procesos.

Bueno Ivar, al final, y aunque un poco tarde, escribí esta pequeña reflexión que te dije que escribiría tanto en Madrid, como en Barcelona, espero que a pesar de estar en español, no se te haya hecho muy duro de leer :).

Como ya sabréis los que seguís el blog de Madrid.NET, os pedimos vuestra opinión para el evento del 22 de enero.

Y bueno, tras ver opiniones, tanto online, como offline, ganaron las mesas redondas.

Y ahora es vuestro turno, lógicamente para que las mesas redondas funcionen, necesitamos vuestra asistencia y colaboración. Colaboración para proponer temas, hablar, dar ideas, y por supuesto vuestra asistencia allí. Así que os animo a todos a que vengáis a este evento.

Aquí os dejo el link con la información de registro.

Nos vemos el 22.

Y es que esto es algo que antes o después ocurre, fallamos en el diseño de una arquitectura, hacemos checkin de código que no compila, tomamos una decisión de implementación totalmente desafortunada, o cualquiera de las múltiples situaciones que se nos dan en un proyecto.

Es algo que nos va a ocurrir, no en vano los errores nos ocurren en nuestra vida diaria, ese típico creo que puedo cargar con un plato más de camino a la cocina que acaba en tragedia, o esta bolsa seguro que aguanta este peso (curiosamente la bolsa dónde llevamos las botellas de cerveza), o más serios como ese típico mensaje/correo que justo cuando le das a enviar, te das cuenta de que lo estás enviando a la persona equivocada, y el contenido, ejem, dejémoslo ahí …

Los errores ocurren, somos humanos, y no podemos evitarlos, tenemos que aprender a convivir con ellos.

Lo realmente importante de esto, es como reaccionamos ante ellos. Para mí es más importante, como cliente, el como alguien me soluciona un fallo, que alguien que “presuntamente” no tiene fallos.

Nuestro primer paso siempre será reconocer el error (es difícil eh), de nada nos valdrá ocultarlo, no va a desaparecer.

Ahora que ya sabemos, y hemos puesto en común el error cometido, lo siguiente es ver la gravedad del error. No todos los errores son igual de graves o de preocupantes, habrá fallos, que simplemente sepamos que tenemos, cuya única acción sea “saber que está ahí”, y vivir con el. No vivir eternamente claro está (o sí …), pero que no sea necesario tomar una acción de modo inmediato.

En el caso de que la gravedad del asunto requiera tomar acciones inmediatas, el resolver este error debe ser prioritario. Es igual que el principio de no desarrollar funcionalidades nuevas mientras haya bugs abiertos.

Por supuesto, en una situación ideal, en la que tengamos una matriz de riesgos, dónde aparezca esta situación, tendríamos un “plan de contingencia”. Pero como suelen decir los americanos, “shit happens”, y no siempre vamos a tener la suerte de tener un plan de contingencia. Esto tampoco debe desanimarnos, las cosas ocurren.

Cada error es un mundo, y no es lo mismo un fallo de diseño que uno en los requerimientos, y desde aquí no pretendo dar una solución universal a la solución de errores.

Lo realmente importante es que cuando detectemos un error por primera vez, el flujo no se convierta en el gráfico que acompaña este post, en el que lo que se intenta es ocultarlo, escurrir el bulto, colarselo a alguien, en defnitiva escapar del problema.

Reitero, el flujo siempre pasa por la comunicación, el famoso triage para evaluar su gravedad, y el tomar las acciones correctivas necesarias antes de continuar, y que el error nos genere un efecto bola de nieve.

Y bueno, cuanto rollo para esta pequeña conclusión, pero es que hoy no estaba demasiado inspirado jeje.

Ahh si, por supuesto, feliz año nuevo a todos, y espero que se cumplan todos vuestros propósitos.

En cuanto a mi, como decía Joe Strummer, “the future is unwritten”, así que simplemente espero ir mejorando día a día, aprendiendo, descubriendo, viajando, y pudiendo hacer las cosas que me mantienen vivo y “despierto” día a día, y dejemos que cada día nos vaya descubriendo nuevas cosas para hacer.

Y también deciros, que no, este año tampoco os libráis de mí, ya me han reconfirmado como MVP de Team System para el 2009 :), muchas gracias a todos los que me leéis, que suponéis una motivación extra para mi.

Pues si, que ha sido de Luis Fraile, que últimamente no ha escrito nada de contenido (si, publicar materiales de mis charlas y anuncios no son contenido).

En fin, que puedo decir, que últimamente no escribo mucho por aquí, y quería dar un pequeño saludo/ping a mis lectores (eoooo ¿hay alguien por ahí?), y decir que vuelvo a la carga.

La cosa es que últimamente he tenido bastante jaleo en general (a todos los niveles), y pocas ganas de escribir, lo cierto es que desde mediados/finales de noviembre aproximadamente he tenido las pilas un poco descargadas por múltiples razones (¿será la edad?), y la poca carga que me quedaba la uso para el trabajo, como es lógico :).

Pero bueno, ahora ya empiezo a estar recargado, a pesar de lo “duras” que están siendo las últimas fiestas, y volveré a la carga de nuevo con VS 2010 (si es que el amigo Bruno nos deja algo para los demás jijij), con mis post filosóficos (por llamarlos de alguna manera), y cualquier otra cosa que se me vaya ocurriendo, como siempre, vaya.

Pues nada compañer@s, que vuelvo a la carga, o al menos eso espero, y espero seguiros teniendo por aquí este año que empieza en muy poquitos días.

Así que, que lo paséis muy bien en este cierre/comienzo de año, y cómo se suele decir, que se cumplan vuestros deseos, propósitos, etc., etc., etc., si, lo se, soy muy poco de este tipo de felicitaciones, por lo que, a pasarlo bien compañer@s.

Hola a todos, bueno últimamente no me prodigo mucho por aquí … lo se, pero bueno, no tengo excusa :).

A lo que iba, el día 18 de diciembre, en las oficinas de Microsoft de Madrid, estaré dando un workshop. En este workshop, de unas 4h de duración, veremos con más detalle los temas de los que ya hablé en el ALM Sessions, y es extensibilidad en Team Foundation Server.

El temario lo tenéis básicamente en mi presentación de ese día, pero aquí nos meteremos más en las tripas del código que enseñaré, y veremos algunas cosas que no vimos en esa charla.

Para poder apuntaros a este y otros workshop que se van a dar, también relacionados ocn las charlas de ese día, aquí os dejo un link con la información:

http://www.microsoft.com/spanish/msdn/spain/eventos/alm/workshops.mspx

Y para el mío del día 18 de diciembre:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032395295&Culture=es-ES

Así que si alguno os animáis, allí nos veremos.

Hola a todos, el final del año se acerca 🙂 Y también el último evento del año de Mad.NUG.

Para este último evento, el día 18 de diciembre, contaremos con alguien muy especial para Mad.NUG, y es Miguel Jiménez, fundador de este grupo de usuarios.

En esta charla, Miguel, va a meterse en las tripas de la tecnología DeepZoom, de ahí que esta charla le hayamos puesto un nivel 300, para que veamos que podemos hacer con esta nueva tecnología de Microsoft basada en Silverlight, y os puedo asegurar que vamos a ver mucho código de como utilizarlo.

Además, siendo estas fechas, siendo la última charla del año, y gracias a Microsoft, contaremos con unos típicos productos navideños para cerrar el evento a las 21:00, y para que nos tomemos todos juntos el turrón jeje.

El evento será, como siempre, en las oficinas de Microsoft en Madrid (Pozuelo), y de 19:00 a 21:00 + extensión del turrón.

Para más detalles del evento, incluido el link de registro, aquí tenéis:

http://madriddotnet.spaces.live.com/blog/cns!6453107D41F04C68!181.entry

---

Este post es cross-posting desde www.lfraile.net y estoy muy interesado en tu opinión. ¿te vienes por aquí y me dejas un comentario?

Ante todo, gracias a los asistentes por venir a mi charla,y espero que os haya gustado lo poco que hemos podido ver.

Dicho esto … mil perdones por el fallo del tiempo, si, yo soy de los que llegan justito al final, y que me enrollo un montón, pero hoy se me ha ido un poco/bastante el tiempo, por lo que pido disculpas a los asistentes. Os prometo copiar cien veces “No volveré a irme de tiempo”, bueno, vale, lo voy a hacer copiando con Excel, pero también cuenta 🙂

Y bueno simplemente dejaros aquí el link para que os descarguéis la presentación, y ponerme a vuestra disposición para las dudas que os puedan surgir.

(Os la pongo en formato 2003 que por una de las dudas surgidas lo mismo no todos tenéis 2007)

Y también aprovecho para recordaros que actualmente se están haciendo una serie de workshops en las oficinas de Microsoft (tanto en Madrid como en Barcelona), acerca de Team System, las fechas completas las tenéis aquí:

http://www.microsoft.com/spanish/msdn/spain/eventos/alm/workshops.mspx

Y deciros que yo doy el workshop de extensibilidad en Team Foundation Server, en Madrid, el 18 de diciembre:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032395295&Culture=es-ES

Una de las nuevas funcionalidades de Visual Studio Team System 2010 (en la versión de Developers), es la de los test “impactados”. Esta pequeña funcionalidad, está destinada a ahorrarnos mucho tiempo a la hora de hacer Test Driven Development en nuestros desarrollos.

Recordemos, que una de las grandes máximas en el TDD, es que los tests se ejecuten rápido, ¿y qué modo más rápido que ejecutar sólo los que se ven afectados por el código que acabamos de tocar?, aqui es dónde entra el análisis de test afectados (queda mejor que impactados) de VS 2010.

Sin embargo, tras hablar con algunos compañeros, parece que no está muy claro como hacer funcionar esta pequeña ayuda, y lo cierto es que está un poco rebuscado, veamos a ver si lo puedo contar aquí.

Antes de nada, decir que doy por supuesto que sabemos crear pruebas unitarias, crear una lista de pruebas, habilitar la cobertura de código (esto ha cambiado un poco en VS 2010), y empezar a crear una Team Build en el Team Explorer, no lo cuento aquí por no hacer un artículo muy largo. Si alguien no conoce este tipo de cosas que lo diga y lo contaremos por aquí. Cualquiera que haya hecho esto en TFS 2008, no debería de tener problemas para seguir estas instrucciones.

Lo primero que tenemos que tener en cuenta, es que, para que VS 2010 se de cuenta de que tests están afectados, necesita información de que tests ejecutan el código que estamos modificando, ¿lógico no?. ¿y de dónde lo saca?, pues de las builds de Team Build, si, necesitamos resultados previos de una Team build.

¿Y que datos necesita de la Team Build?, pues lo primero necesitamos, que las pruebas que se ejecuten durante la Team Build, publiquen información de cobertura de código (code coverage). Esta es la primera base para esta información. Además, con las nuevas Team Build (basadas en WorkFlow), necesitamos ejecutar un paso más, que es la publicación del análisis de test afectados, que por defecto está DESACTIVADA. Vayamos al grano.

Una vez que ya tenemos nuestro proyecto, con sus listas de pruebas y la cobertura de código habilitada para el ensamblado que estamos probando, hmmm vale, si estoy dando por supuesto que todos sabéis hacer esto, si no sabéis, dejadme un comentario y lo cuento otro día. Vamos a crear una nueva Team Build.

Y aquí ya empezamos con VS 2010, una vez que estamos en la pantalla de crear una nueva Build, tenemos una sección “Process”, si pulsamos en ella veremos lo siguiente:

Lo primero, pulsaremos el primer link (“Select solutions …”), que nos llevará aquí:

 

Dónde con el botón de los “…” seleccionaremos los proyectos que queremos compilar. Después, seleccionamos el link de “Select tests”, y nos llevará de nuevo a la sección anterior pero esta vez a TestProjects, volvemos a pulsar los puntos suspensivos, y se nos mostrará la ventana para seleccionar el fichero “.vsmdi” que corresponde con los tests que queremos ejecutar (y sus correspondientes listas).

Y ahora viene la magia para los impacted tests, ya que tenemos que activar unas cuantas opciones del proceso.

La primera es esta:

Vamos desplegando el proceso de este modo: “Select an agent …”, “Compile and test”, “Get Impacted tests”, y ohhhh, vemos que está a false (a la derecha), pues la ponemos a true.

Seguimos desplegando por la rama “Test All Projects”, “Test a Project”, “Run MSTest …”, y llegamos aquí:

Ohhh, segunda sorpresa, la actividad (a la derecha) “PublishTestImpactInformation” está a false, pues nada, la ponemos a true.

Y seguimos adelante, y en la sección “Publish the Test Impact Data”:

Ohhh, tercera sorpresa, también a false, pues nada, la ponemos a true.

Con esto (y el resto de propiedades de la Team Build habituales), ya tenemos la Build preparada para tener información de los test afectados.

Pero hay más trucos, debemos de ejecutarla al menos DOS veces antes de tener información, la primera vez, se establece la línea base de código, y la segunda ya tenemos la información necesaria para el análisis.

Una vez que la hemos ejecutado dos veces (y que haya funcionado con información de cobertura incluida), ya estamos en disposición de probar esta funcionalidad.

Para ello, abrimos la solución de nuevo (en caso de haberla cerrado), y seleccionamos el menú “Test”, “Windows”, “Test Impact view”.

Y más “trucos”, tenemos que seleccionar en esta vista, el proyecto al que pertenece, y la build de la que queremos obtener la información de tests:

Con esto, y si hemos seguido todos los pasos, una vez que empecemos a modificar código, y grabemos los cambios (sin necesidad de hacer check-in), veremos como en la sección de Impacted Tests, nos van apareciendo los tests a los que afectan estos cambios.

En fin, es un poco lioso, lo se, y espero que para la versión final esto cambie (ya les he dado el feedback), pero por ahora, eso es todo lo que tenéis que hacer 🙂

Y bueno, para cualquier duda aquí (http://www.lfraile.net) me tenéis.