El Bruno

Buenas,

el escenario que voy a detallar es muy poco común, pero como bien nos ha enseñado Murphy existen situaciones donde necesitamos que nuestras compilaciones interactuen con el escritorio de Windows.

Imaginaos que una inocente prueba unitaria al momento de probar una función totalmente intrascendente desencadena un proceso al que llamaré [X]. Hasta aquí todo perfecto las pruebas en local funcionan perfectamente, pero luego el servidor de compilación se nos va de vacaciones cuando quiere ejecutar esta prueba. (nota escrita: el amigo Ibon está escribiendo bastante sobre Unit Testing, se los recomiendo)

Pero bueno, después de un par de horas y varios litros de café, vemos que dentro del proceso [X] un componente de backend utiliza una instancia de Internet Explorer para “hacer algo con la misma” y luego la destruye (nota mental: recordar llevar el hacha, averiguar la mente maligna creadora de este código y comenzar a cortar miembros a cascoporro).

Este es un escenario bastante improbable pero no imposible, asi que no entraré en detalles de diseño y opiniones adjuntas; pero sí, como siempre trato de hacer en el blog, comentaré la solución al problema.

• Abrir una sesión en el servidor de compilación TFS utilizando la cuenta de servicio de TFS Build (usualmente es DOMAIN\TfsBuild)
• Abrir una instancia del Command Prompt de Visual Studio
• Ejecutar el comando TFSBuildService, esto crea una instancia “interactiva” del servidor de build en el puerto 9192 (puerto por defecto)
• Dejar la sesión abierta
• Ya en este punto, podemos lanzar nuestros builds utilizando un Agente de Build en el puerto 9192 y el mismo se ejecutará en la sesión del punto anterior.

Sin ser una solución elegante, funciona.

Saludos @ Silverlight Hell

El Bruno

PD: el siguiente link seguramente será de ayuda http://blogs.msdn.com/buckh/archive/2007/07/20/tfs-2008-build-agent-configuration-options.aspx

Crossposting from ElBruno.com