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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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