Можно ли использовать рабочие пространства TFS без привязки к конкретной машине?

Question

Итак, у меня есть ситуация, когда у нас есть проект с 10 разработчиками. Каждому разработчику, когда они приходят в течение дня, случайным образом выдают машину для использования в тот день для разработки. Имена машин разные, скажем DEV01 - DEV10. На момент выдачи разработчикам машины идентичны, и изменения, внесенные разработчиками в течение дня, не сохраняются на машинах (изменения исходного кода хранятся в TFS, а не локально). Это, конечно, на самом деле виртуальные машины, но на самом деле это не имеет отношения к делу.

Проблема в том, что каждое утро разработчики сталкиваются с 3 проблемами:

1) Возможно, назначенный им компьютер не совпадает с последним назначенным им. Например, DevMan A мог вчера использовать DEV04 и получить DEV06 сегодня. Его определения рабочего пространства теперь связаны с DEV06; он должен создать новое рабочее пространство или перенести старое рабочее пространство в DEV04.

2) Возможно, назначенная им машина использовалась вчера, и некоторые сопоставления могут конфликтовать. Например, у DevMan A сегодня может быть DEV04, и он хочет создать рабочую область, отображающую папку проекта в «C: \ MyProj \ Solution». Однако вчера у DevMan B был DEV04, и он использовал ту же папку проекта. TFS теперь жалуется.

3) Это может быть первый раз, когда они находятся на данной машине. Теперь им необходимо воссоздать для этой машины все сопоставления управления исходным кодом для новой машины.

Все эти проблемы могут быть решены простым способом в каждом конкретном случае, но это действительно снижает производительность с утра. Мы бы предпочли, чтобы определения рабочего пространства TFS были «смягчены», чтобы они не включали имя машины в определение. За исключением этого, если кто-либо знает о решении вышеуказанных проблем, которое может запускаться автоматически или с ограниченным вмешательством пользователя, это также было бы идеально.

Answer 1

Во-первых, самый очевидный ответ - посвятить машины пользователям.

Во-вторых ... если вы действительно хотите решить проблему как указано:

Вы не можете использовать рабочие пространства, не назначая их конкретному компьютеру. Это предположение подразумевается в продукте. Но вы можете обмануть это:)
Предупреждение: Кажется, этот рецепт работает, но я лично не запускал проект, используя его.

1. Назначьте имя «Виртуальной» машины для каждого пользователя, т. Е. UseridVM
2. Для каждой виртуальной машины необходима следующая (постоянная или запускаемая) настройка:
   • создать новую переменную среды "Переменная пользователя", т.е. _CLUSTER_NETWORK_NAME_ = UseridVM
3. Приятно иметь: использовать виртуальный жесткий диск, который выделен для идентификатора пользователя и сопоставлен (или смонтирован с помощью скрипта) в «D:», который следует за пользователем от ВМ до ВМ.

Теперь, когда пользователь открывает Visual Studio, рабочая область будет использовать заданное значение «UseridVM» в качестве имени машины, поэтому на каждой машине будет найдено одинаковое рабочее пространство.

Если у вас нет постоянного виртуального жесткого диска, тогда каждый пользователь должен обязательно выполнить «настоящую» «Получить последнюю версию» (Получить определенную версию, установите все флажки) при запуске в течение дня, потому что рабочая область запоминает, что файлы уже были загружены и не будут перезагружать их, если будет казаться, что они уже существуют.

Answer 2

1.) Для каждой рабочей станции, на которой вы собираетесь работать, вам нужно определить рабочее пространство (удаленное <=> локальное сопоставление). Вы можете хранить исходные файлы в сети (не рекомендуется из-за кэширования VS), но локальное рабочее пространство (определение отображения) должно существовать на конкретном ПК для конкретного пользователя.

2.) Создайте отдельные локальные папки для каждого разработчика, чтобы не допустить путаницы разных людей, работающих над одной и той же папкой и получающих последние новости о проверенном коде других. Например:

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

3.) Это, вероятно, вызовет много дискуссий, но я рекомендую сопоставить корень вашей TFS с вашей локальной рабочей областью, например. Отображение DevManA:

$/ to C:\Projects\DevManA\

Тогда, когда вы проверяете проекты, вы получите структуру:

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

и т.д.

Это простое и быстрое картирование, которое каждый может сделать за 5 секунд, и вы готовы к работе. Тогда у всех на диске одинаковая раскладка, как в TFS, которая также легче "вписывается в мозг".

Answer 3

Я не знаю, будет ли это соответствовать требованиям, указанным в вопросе, но вы можете проверить это:

http://blogs.msdn.com/granth/archive/2009/11/08/tfs2010-public-workspaces.aspx

В TFS 2010 добавлены открытые / общие рабочие пространства, которые могут использоваться несколькими пользователями на одном компьютере.

Answer 4

Рабочее пространство можно разместить на общем сетевом диске, поэтому не имеет значения, на какой машине (виртуальной или другой) зарегистрирован разработчик. Это отлично работает, но вам также придется настроить некоторые вещи COM один раз , чтобы они были довольны.