MS Team Foundation Server в распределенных средах - полезные советы

Кто-нибудь использует Team Foundation Server в географически распределенной команде? Мы в Великобритании, пытаемся работать с командой в Австралии, и мы находим это довольно сложным делом.

Наши главные две проблемы:

  1. Вещи проверяются для нас, и мы не просим о получении последних.
  2. Даже при использовании прокси-сервера, большинство событий занимает некоторое время.

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

Кто- нибудь на самом деле использует TFS таким образом, ежедневно с (относительным) успехом?

Если да, есть ли у вас какие-либо подсказки, советы, хитрости или хитрости, о которых стоит знать?

PS Обновление до CruiseControl.NET не вариант.

14.08.2008 13:27:40
Используете ли вы TFS 2005 или 2008. Потому что 2008 сделал огромное количество улучшений прокси. А также в новом сервис-паке исправлено несколько ошибок. Дайте мне знать, что это поможет мне с чего начать, потому что я использовал прокси и у меня не было никаких проблем. Самое большое, что я обнаружил, это то, что интернет-соединение между прокси и TFS должно иметь низкую задержку. Также я обнаружил, что иногда прокси является лучшим решением, если вы работаете на двух разных доменах AD. Если вы подключены к той же сети, устанавливаете VPN или другое безопасное соединение между этими двумя местами, вы
Nick Berardi 14.08.2008 13:37:54
@Nick Berardi Мы используем 2008. Время пинга составляет ~ 310 мс, что чуть ниже рекомендуемого максимума в 350 мс . Это примерно так же хорошо, как между Великобританией и Австралией. Я предполагаю, что туннелирование через планету могло бы помочь, это сбрило бы приблизительно 100 мс, но я не думаю, что бюджет будет одобрен. :-) Как вы думаете, это будет проблемой из-за этого? Мы можем жить с этим, но что за случайные проверки?
Iain Holder 14.08.2008 13:45:19
Случайные проверки - это Visual Studio, если кто-то найдет и заменит его, проверит все необходимые файлы. Если файл кода имеет вложенные файлы, он проверяет все вложенные файлы. Если вы запускаете тест, файл vsstest извлекается. И так далее. Вы также должны помнить, каковы рекомендуемые Microsoft минимумы. Они находят минимум, видя, как низко они могут уменьшить системные ресурсы, прежде чем вы захотите застрелиться. Я считаю, что Windows Vista рекомендуется около 512 МБ ОЗУ. Очевидно, мы все знаем, что что-то под 2 ГБ будет болезненным. Таким образом, вы в основном правы
Nick Berardi 14.08.2008 13:56:22
3 ОТВЕТА
РЕШЕНИЕ

Обязательно обновите до TFS 2008 и Visual Studio 2008, так как это версия Team System для v2. Исправляет множество мелких и средних проблем.

Что касается «случайного извлечения вещей», то это почти всегда связано с тем, что Visual Studio решила редактировать файлы от вашего имени. Попробуйте получить последние сведения из Team Explorer, не открывая ничего в Visual Studio, и посмотрите, сохраняется ли такое поведение. Могу поспорить, что не будет!

Несколько серверов TFS - плохая идея. Убедитесь, что ваш прокси настроен правильно, так как он кэширует повторяющиеся GET. Тем не менее, TFS - это модель, подключенная к серверу, поэтому она всегда будет работать немного медленнее, чем настоящие «автономные» системы контроля версий.

Кроме того, если бы вы могли отредактировать свой вопрос так, чтобы он содержал более конкретные жалобы или детали, это помогло бы - сейчас это ужасно расплывчато, поэтому я не могу ответить очень хорошо.

2
14.08.2008 13:48:02
Не получат ли последние новости от Team Explorer обход прокси-сервера? Я попытался добавить прокси к нему, и это не нравится. Возможно, решение состоит в том, чтобы сначала получить последние новости дня через Team Explorer, а затем использовать прокси для остальных. Я полагаю, что пришло время приготовить чай и провести гибкую встречу.
Iain Holder 14.08.2008 14:00:39
@IainMH Как Джефф сказал, что настройки прокси-сервера должны быть подстроены под ваши индивидуальные практики в вашем регионе. Конфигурация по умолчанию почти никогда не работает для большинства людей. Вы, вероятно, должны взглянуть на Управление удаленными подключениями из MSDN. Также я нахожу эту статью и тестирование и управление производительностью кеша .
Nick Berardi 14.08.2008 14:07:48

Насколько я понимаю, вы можете иметь несколько серверов приложений TFS в разных местах. Они либо могут общаться с одним и тем же SQL Server, либо вы можете использовать зеркалирование SQL Server. Наличие собственного локального TFS-сервера, скорее всего, ускорит время разработки.

0
14.08.2008 13:39:12
Это на самом деле не работает, потому что это делает управление конфликтами кошмаром. Потому что конфликты объединяются на стороне клиента, а затем регистрируются не на сервере. Поэтому, когда вы собираетесь синхронизировать базы данных, у вас возникают проблемы. Также наличие нескольких серверов TFS также является проблемой, если только они не исправили это в последнее время, потому что все в базе данных основано на домене сервера TFS, который изначально его настраивал.
Nick Berardi 14.08.2008 13:44:42

Мы используем TFS с несколько распределенной командой - они не слишком далеко, но подключаются через медленную и ненадежную VPN.

Для вашей первой проблемы, получить последний при оформлении заказа не поведение по умолчанию. (Вот объяснение ) Хотя есть надстройка , которая сделает это за вас.

Вот рабочий процесс, который работает для нас:

  1. Получить последнюю
  2. Построить и убедиться, что ничего не сломано
  3. Работа (изменения отложены)
  4. Получить последний снова
  5. Справиться с конфликтами слияния
  6. Построить и убедиться, что ничего не сломано
  7. Регистрироваться

[править] ОК, похоже, вы перефразировали эту часть вопроса. Да, Джефф прав, VS решает проверить некоторые файлы "для вас", такие как файлы sln и proj. Он также автоматически извлекает любой исходный файл, который вы редактируете (но это то, что вы хотите, правда? Хотя вы можете изменить этот параметр в меню Инструменты> Параметры> Управление исходным кодом)

По-видимому, прокси требует некоторого времени для наращивания (мы его не используем), но как только он кэширует большую часть дерева, он должен быть довольно быстрым. Можете ли вы провести мониторинг и найти узкие места?

Что-нибудь еще доставляет вам неприятности, кроме как получить последнюю информацию о покупке и скорость?

1
14.08.2008 14:34:37