Buenas,
en Team Foundation Server 2010 se cambió radicalmente la arquitectura de servidor de Team Foundation. Se introdujo el concepto de Team Project Collection, como elemento para organizar y agrupar Team Project, además de brindar la capacidad de aislar contenidos y facilitar el proceso de backup y mantenimiento general de Team Foundation Server. Otra de las grandes apariciones estuvo relacionada con Team Build 2010, el concepto de Build Controller y Build Agents, nos brinda una posiblidad muy amplia cuando tenemos que configurar entornos de compilación.
Perooooo (lo siento hay un pero y uno muy feo), existe una limitación asociada a un servicio de Build:
UN SERVICIO DE BUILD SOLO PUEDE ESTAR ASOCIADO A UN TEAM PROJECT COLLECTION
Esto significa que si tenemos 3 Team Project Collections, como muestra la siguiente imagen,
en el mismo servidor solo podremos tener nuestro servicio de build apuntando a uno de las 3 Team Project Collections. Es más, si desde un Team Project queremos configurar una definición de build en una TPC que no esté configurada con el servicio de Build, pues tendremos un error similar a este:
1: ---------------------------
2: Microsoft Visual Studio
3: ---------------------------
4: TF225001: Creating a build definition requires a build controller be defined
5: for this team project collection. There may not be any controllers configured
6: or you may not have permissions to view them.
7: Contact your Team Foundation Server administrator.
8: ---------------------------
9: OK
10: ---------------------------
El siguiente tutorial describe los pasos NO OFICIALES para configurar un nuevo servicio de Build apuntando al TPC [TPCBuild], y asumiendo que la configuración del servicio por defecto apunta al TPC [ALMBook]. Repito, esto no está soportado por el equipo de producto, asi que te recomiendo estudiar otras alternativas antes de tomarlo como una solución de soporte oficial.
Tutorial
1. Abrir una ventana de comandos con permisos de administrador.
2. A continuación crearemos un nuevo servicio de Windows para Team Build. Para esto ejecutamos el siguiente comando:
sc.exe create [%Nombre del Servicio%] binpath= “[%Path de TFSBuildServiceHost.exe%] /NamedInstance:[%TFSServerInstance%]” DisplayName= “[%Display Name del Servicio%]”
Donde para mi ejemplo, los valores quedarían de la siguiente forma
sc.exe create “TeamBuildTPCBuild” binpath= “C:\Program Files\Microsoft Team Foundation Server 2010\Tools\TfsBuildServiceHost.exe /NamedInstance:TeamBuildTPCBuild” DisplayName= “Visual Studio Team Foundation Build Service Host (TPCBuild)”
3. Una vez ejecutado el comando, podremos ver en el listado de servicios de Windows, el nuevo servicio con el nombre y descripción definidos en el paso anterior:
4. A continuación, para poder administrar el servicio de Build desde la Consola de administración de Team Foundation, modificaremos la variable de entorno TFSBUILDSERVICEHOST con el valor que utilizamos en [%TFSServerInstance%], por ejemplo:
SET TFSBUILDSERVICEHOST=TeamBuildTPCBuild
5. Una vez seteado este valor, ya podemos abrir la consola de administración de Team Foundation, pero teniendo en cuenta que debemos abrirla desde la misma consola de comandos en la que estamos trabajando. Dependiendo de la ubicación donde se haya instalado TFS, el siguiente comando puede ser diferente, pero en la instalación por defecto la consola se lanza con:
“C:\Program Files\Microsoft Team Foundation Server 2010\Tools\tfsmgmt.exe”
6. Como podemos ver en la siguiente imagen, la información que veremos para el servicio de Build está asociada con el TPC [ALMBook], debemos detener el servicio y desregistrar (Unregister) el mismo para actualizar la información para este servicio.
7. Una vez detenido y eliminado el registro, podremos ver como la configuración de Team Build está limpia y lista para ser configurada.
8. Configuramos el servicio apuntando al TPC [TPCBuild] y cambiamos el puerto por defecto de 9191, a otro puerto. Este punto es muy importante ya que si lo registramos en el mismo puerto que el otro servicio de Build, pues … no funciona.
9. Creamos un Build Controller y un Build Agent, teniendo en cuenta que los mismos estarán asociados al servicio de Windows que creamos en el paso anterior.
10. Finalmente comentar, como bien dice Jim Lamb en su blog, es importante cambiar el path por defecto donde apunta el workspace de trabajo del Team Agent, ya que como por defecto se utiliza el número del AgentId, pues es probable que se corresponda con el mismo path del “otro agente”.
11. Ya podemos comenzar a utilizar este nuevo servicio de build.
Saludos @ Home
El Bruno
El Bruno 
Leave a comment