2008-08-14 6 views
5

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

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

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

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

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

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

P.S. Переход на CruiseControl.NET не является вариантом.

+0

Используете ли вы TFS 2005 или 2008. Поскольку в 2008 году было сделано огромное количество улучшений прокси. Как и новый пакет обновления, исправлено несколько ошибок. Дайте мне знать, что это поможет мне, с чего начать, потому что я использовал прокси-сервер, и у меня не было никаких проблем. Самое большое, что я обнаружил, это то, что интернет-соединение между прокси-сервером и TFS должно иметь низкую задержку. Также я обнаружил, что иногда прокси-сервер является лучшим решением, если вы работаете с двумя разными доменами AD. Если вы находитесь на том же самом, настройте VPN или какое-либо другое безопасное соединение между двумя местами, вы: –

+0

Случайные проверки - это Visual Studio, если кто-то находит и заменяет его, проверяет все необходимые файлы. Если в файле кода есть подфайлы, он проверяет все подфайлы. Вы запускаете тест, файл vsstest проверяется. И дальше, и так далее. Вы также должны помнить, какие рекомендации рекомендованы Microsoft. Они находят минимальный вид, видя, как низко они могут уменьшить системные ресурсы, прежде чем вы захотите застрелить себя. Я полагаю, операционная система Windows Vista рекомендуется около 512 МБ. Очевидно, все мы знаем, что что-то под 2GB будет болезненным. Таким образом, вы в основном правы на –

+0

@Nick Berardi. Мы используем 2008. Время ping составляет ~ 310 мс, что чуть ниже [рекомендуется максимум 350 мс] (http://msdn.microsoft.com/en-us/library /ms404867.aspx). Это примерно так же хорошо, как и между Великобританией и Австралией. Я предполагаю, что туннелирование через планету могло бы помочь, это сбрит около 100 мс, но я не думаю, что бюджет будет одобрен. :-) Как вы думаете, из-за этого это будет проблемой? Мы можем жить с этим, но что такое сделка со случайными проверками? –

ответ

2

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

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

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

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

+0

Не стал бы последним из Team Explorer обойти прокси? Я попробовал добавить к нему прокси-сервер, и ему это не нравится. Возможно, решение состоит в том, чтобы сначала получить последнюю информацию через Team Explorer, а затем использовать прокси для остальных. Полагаю, пришло время приготовить чай и провести энергичную встречу. –

+0

@IainMH Как Джефф сказал, что конфигурация прокси-сервера должна быть изменена для ваших индивидуальных практик в вашем регионе. Конфигурация по умолчанию почти никогда не работает для большинства людей. Вероятно, вы должны взглянуть на [Управление удаленными подключениями] (http://msdn.microsoft.com/en-us/library/ms253156.aspx) из MSDN.Также я нахожу эту статью и [тестирование и управление производительностью кеша] (http://msdn.microsoft.com/en-us/library/ms252455.aspx). –

0

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

+0

Это на самом деле не работает, потому что это делает управление конфликтами кошмаром. Поскольку конфликты объединяются на стороне клиента, а затем проверяются не на сервере. Поэтому, когда вы запускаете синхронизацию баз данных, в которые вы запускаете, вы можете столкнуться. Также наличие нескольких серверов TFS также является проблемой, если только они не исправили это недавно, потому что все в базе данных основано на домене сервера TFS, который изначально настроил его. –

1

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

Для вашей первой проблемы, получить последние на checkout не по умолчанию. (Вот explanation) Существует add-in, который сделает это за вас.

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

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

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

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

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