espacios de trabajo lata TFS usarse sin estar atado a una máquina específica?

Question

Así que tengo una situación en la que tenemos un proyecto con 10 desarrolladores. Cada desarrollador, cuando entran en el día, se emite al azar una máquina a utilizar para el desarrollo de ese día. Los nombres de los equipos son diferentes, por ejemplo DEV01 - DEV10. En el momento en que se emiten a los desarrolladores, las máquinas son idénticas, y no hay cambios en los desarrolladores hacen durante el día se conservan en las máquinas (cambio de código fuente se almacenan en TFS, no a nivel local). Estos son, por supuesto máquinas virtuales en realidad, pero eso no es realmente relevante para el punto en cuestión.

El problema es que cada mañana, los desarrolladores encuentran con 3 temas:

1) La máquina que se asignan no puede ser la misma máquina que eran última asignada a. Por ejemplo, DevMan A podría haber usado DEV04 ayer, y recibió DEV06 hoy. Sus definiciones de espacio de trabajo están vinculados a DEV06; debe crear un nuevo espacio de trabajo, o migrar el antiguo espacio de trabajo para DEV04.

2) La máquina que se asignan pueden haber estado en uso ayer, y algunas de las asignaciones pueden entrar en conflicto. Por ejemplo, podría tener un DevMan DEV04 hoy, y deseo de crear un espacio de trabajo de mapeo de la carpeta del proyecto en "C: \ MyProj \ Solution". Sin embargo, DevMan B tenía DEV04 ayer, y utilizó la misma carpeta del proyecto. TFS ahora se queja.

3) Esta puede ser la primera vez que están en una máquina determinada. Ahora necesita volver a crear para esta máquina todas sus asignaciones de control de fuente para la nueva máquina.

Todos estos problemas pueden ser resueltos de una manera sencilla sobre una base caso por caso, pero sí algunos savia de la productividad de la mañana. mucho Preferiríamos si las definiciones de espacio de trabajo TFS podrían ser 'relajado', de tal manera que no incluían el nombre de la máquina en la definición de alguna manera. Aparte de eso, si alguien tiene conocimiento de una solución a los problemas anteriores que se pueden ejecutar de forma automática, o con la intervención de usuario limitada, que también sería ideal.

Answer 1

En primer lugar, la respuesta es obvia super-máquinas para dedicar a los usuarios.

En segundo lugar ... si realmente quiere resolver el problema como se indica:

No se pueden utilizar espacios de trabajo y sin asignarlos a una máquina específica. Esta suposición está implícita en el producto. Pero se puede engañar a él :)
Advertencia: Esta receta parece que funciona, pero no he dirigido personalmente un proyecto de usarlo.

1. Asignar un "Virtual" nombre de la máquina para cada usuario, es decir UseridVM
Se necesita configuración
2. Para cada máquina virtual lo siguiente (persistente o puesta en marcha con guión):
   • crear una nueva variable de entorno "variable de usuario" es decir _CLUSTER_NETWORK_NAME_ = UseridVM
3. bueno tener: Utilice un disco duro virtual que se dedica a la identificación del usuario y se asigna (o montado utilizando un script) a "D:". Que sigue al usuario de VM a VM

Ahora, cuando el usuario abre Visual Studio, el espacio de trabajo utilizará el valor especificado "UseridVM" como el nombre de la máquina, por lo tanto el mismo espacio de trabajo se puede encontrar en cada máquina.

Si no tiene un disco duro virtual persistente, a continuación, cada usuario debe estar seguro de hacer un 'real' "Obtener la última" (Obtener versión específica, marque todas las casillas) al iniciar el día, porque los espacios de trabajo lo memoriza los archivos que ya se han descargado y no volver a descargar si se siente que ya existen.

Answer 2

1.) Por cada estación de trabajo que se va a trabajar en, es necesario definir un espacio de trabajo (mapeo remoto <=> local). Puede almacenar archivos de origen en la red (no recomendamos esto debido a VS el almacenamiento en caché), pero espacio de trabajo local (definición de asignación) tiene que existe en PC específico para el usuario específico.

2.) Crear carpetas locales separados por desarrollador para prevenir lío de diferentes personas que trabajan en la misma carpeta y conseguir más reciente sobre desprotegido código de los demás. Por ejemplo:

c:\Projects\DevManA\...
c:\Projects\DevManB\... etc.

3). Esto probablemente hará que muchos de los debates pero recomiendo el mapeo raíz de sus TFS a su área de trabajo local, por ejemplo. DevManA mapeo:

$/ to C:\Projects\DevManA\

A continuación, cuando se está comprobando a cabo proyectos obtendrá estructura:

c:\Projects\DevManA\TFSProject1\..
c:\Projects\DevManA\TFSProject2\..
c:\Projects\DevManA\TFSProject3\..

etc.

Esto es fácil y rápido a todo el mundo mapeo puede hacer en 5 segundos y ya está listo para ir. Entonces todo el mundo tiene el mismo diseño en el disco como en TFS que también "se ajusta el cerebro" más fácilmente.

Answer 3

No sé si esto va a cumplir con los requisitos indicados en la pregunta, pero es posible comprobar esto:

http: //blogs.msdn .com / granth / archivo / 2009/11/08 / tfs2010-público-workspaces.aspx

pública TFS 2010 ha añadido / espacios de trabajo compartidos que pueden ser utilizados por varios usuarios en la misma máquina.

Answer 4

Se puede colocar el espacio de trabajo en una unidad de red compartida, por lo que no importa qué máquina (virtual o no) el desarrollador se registra en. Esto funciona bien, pero también tendrá que configurar algunas cosas COM una vez para que crezca feliz.