Как оценить переход на Team Foundation Server

10

Моя команда разработчиков в настоящее время использует следующее программное обеспечение в нашем рабочем процессе:

  • JIRA
  • Бамбук (непрерывная интеграция Atlassian)
  • Greenhopper (управление гибкими проектами Atlassian)
  • впадение
  • Git, размещенный на BitBucket
  • Visual Studio 2012

Как вы можете видеть, мы вложили значительные средства в экосистему Атлассиана. Мы рассматриваем переход на TFS, чтобы мы могли получить тонкости продвинутых интеграций Visual Studio, таких как обзоры кода и, что более важно, Microsoft Test Manager.

Мой предыдущий опыт работы с TFS был в 2005 или 2008 году (я не помню), и у меня остались плохие воспоминания об этом, хотя и не такие плохие, как у меня с ClearCase.

На какие критерии мы должны обратить внимание, чтобы правильно оценить наш переход на TFS?

Сэм
источник
4
Я перешел из компании на Git в компанию с TFS 2008, и это невероятно больно. Я слышал, что 2012 год намного лучше ... но сейчас мы не можем обновиться. Как это в настоящее время, хотя ... я бы убил, чтобы вернуться к мерзавцу :(
Саймон Уайтхед
1
Это правильно. TFS 2008 было сложно поддерживать и использовать. Но есть сильная положительная тенденция: TFS 2010 был намного лучше, чем 2008, TFS 2012 намного лучше, чем 2010. Он гораздо более удобен в обслуживании и имеет отличный веб-интерфейс, поэтому его могут использовать люди без Visual Studio (тестировщики и владельцы продуктов и т. д.)
Андрей Зубов
@SimonWhitehead, как кто-то, кто перешел с TFS2008 на TFS2012, различия на фундаментальном уровне пользователя не сильно изменились - есть новые биты по краю (например, обзоры кода, веб-страница с разбором и т. Д.), Но вы все равно ненавидите это. Обновление ... забудьте, вам нужно выполнить чистую установку и скопировать ваши данные.
gbjbaanb
4
Даже TFS 13 не имеет ничего общего с JIRA Agile. Их нынешняя реализация "Kanban board" - это жалкая попытка оживить этого мертвого ребенка. Заменить Cofluence вы вообще ничего не найдете. Я не уверен, почему кто-то должен рассмотреть переход от стека Atlassian к стеку TFS. Я использую TFS много лет, и я никогда не был доволен этим, как и мои коллеги.
Алексей Зимарев
Поскольку вы уже инвестировали в экосистему Atlassian, я удивлен, что никто не упомянул Atlassian Stash , который работает поверх Git и предоставляет вам такие функции, как управление доступом к репозиторию, запросы на извлечение, обзоры кода и стратегии автоматического слияния. Это довольно мило.
Майк Чемберлен

Ответы:

17

Небольшой опрос Мартина Фаулера много говорит о состоянии TFS в предыдущие годы. «опасно» совершенно верно. (Я думаю, это относится к тому, что он не распознает изменения, сделанные вне VS, поэтому вы можете создать проект WCF, затем использовать внешний инструмент svcutil для создания вашего клиента, а затем проверить все ваши изменения в ..., но TFS будет счастливо игнорировать изменения вашего клиента, потому что они не были сделаны внутри VS).

Вы должны посчитать стоимость: необходимая версия VS для получения положительных героев - например, для проверки кода требуется Premium Edition, которая значительно дороже, если вы получаете VS через MSDN. Кроме того, доступ к системе для пользователей не-VS - это хорошо, но если они хотят получить полный доступ вместо сокращенного веб-представления, вам придется выложить для них клиентские лицензии. Общая стоимость TFS может быть довольно большой. Даже недавний отчет Forrester(по заказу Microsoft, поэтому вам нужно немного прочитать между строк) говорит, что TFS требует значительной административной поддержки - 2 консультанта и 6 администраторов (которые потратили 25% своего времени) были обязаны поддерживать TFS для их тематического исследования 122 пользователей (работает с 4,5 администраторами для этих 122 пользователей ... это много по сравнению с тем, что я настраиваю и поддерживаю полноценное решение SVN, а также выполняю свою повседневную работу). TFS может занять много усилий, чтобы продолжать работать так, как ожидают люди.

По моему опыту работы с TFS2012 (не обращайте внимания на предыдущие версии, потому что это дерьмо), это очень сложное системное администрирование, особенно если вы выходите за пределы предварительно заданной настройки. Например, если вы используете MSBuild для сборки всего, все в порядке. Но если, скажем, у вас есть загрузка старых проектов .vdproj, которые больше не поддерживаются MSBuild, вам нужно отредактировать огромный скрипт сборки xaml, чтобы он создавал эти проекты. После нескольких дней работы над этим лучшее, что я мог сделать, - это перестроить решение, передав его в devenv, и даже тогда было невозможно получить результаты сборки в сводке сборки. Аналогичные результаты были получены другими командами, которые использовали NUnit для своих тестов - если вы используете встроенный MSTest, то он работает. В противном случае, вы в значительной степени чучела.

Как пользователь, я считаю, что интеграция - это скорее неприятность. Я предпочитаю TortoiseSVN, и я делаю почти всю свою работу с SCM через нее (так как это потрясающий инструмент). С TFS вы получаете новый экран внутри VS для каждой операции. Таким образом, у вас есть новая вкладка в вашей среде для обозревателя команды, и еще одна для сборок, и еще одна для каждой сводки сборок, которую вы хотите увидеть (и если вы хотите увидеть детали сборки, например, ошибка, у вас есть нажать слишком много ссылок). Я обнаружил, что количество документов, которые я открыл при использовании TFS, было больше, чем исходные файлы!

То же самое относится и к проверкам, для внесения изменений требуется перебрать несколько вкладок на панели «Ожидающие изменения» в VS, чтобы назначить рабочий элемент и оставить комментарий для ваших проверок. Это небольшая вещь, но я нашел это раздражающим, поскольку я привык к более обтекаемым инструментам.

Расширение системы сборки было еще одной областью, которой мне не хватало. Добавление новых функций в сборку затруднено из-за конфигурации xaml, и получение результатов этих функций на экранах сборки либо очень, либо очень сложно, или невозможно. Поэтому, если вам нравится добавлять такие вещи, как сложность кода или статический анализ, или даже автоматическое тестирование с помощью, скажем, selenium или развертываний ... забудьте об этом. Если только вы не используете инструменты Microsoft для этих аспектов (например, fxcop).

Обновление рабочего процесса было еще одним препятствием - хотя powertoys очень помогли, было все еще неловко правильно настроить рабочий процесс, и вы все еще не можете настроить доску Scrum на информацию, которую вы действительно хотите видеть - опять же, вы получаете значения по умолчанию или ничего ,

Объединение также было болезненным, я думаю, что есть очень веская причина, по которой MS приняла git для TFS (обратите внимание, что это работает только с новыми проектами TFS, вы не можете конвертировать из TFS в git backends).

В общем, все не так плохо, как работает, но я обнаружил, что многие другие инструменты намного лучше. Недостатком этих инструментов является то, что они не полностью интегрированы, но, по-моему, это является сильной стороной, так как вы можете выбирать лучшие биты, которые вы хотите. С TFS вы получаете в значительной степени то, что кто-то еще хочет от вас. Если вы решите, что система ошибок в TFS оставляет желать лучшего (и я думаю, что так и будет), вам будет сложно перейти на другую.

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

Хотя я бы попробовал, скачал 30-дневные пробные версии и установил их. При оценке не забывайте вносить небольшие изменения здесь и там, а не просто использовать их для проверки исходного кода, регистрации с рабочим элементом и получения отчетов на основе этого рабочего элемента. Попробуйте назначить регистрацию нескольким рабочим элементам и попробуйте объединить рабочие элементы как связанные. Попытайтесь включить что-то другое в систему сборки, посмотрите, как получать ежедневные отчеты о ходе работ из служб отчетов, связывать документ с требованием рабочего процесса и прослеживать его посредством сортировки ошибок до кодирования, чтобы построить для доработки, а затем выпустить. Ветви и слияния много. Если вы не можете легко делать все эти вещи, то вы можете придерживаться мерзавца. Нет смысла использовать TFS, если вы не используете большинство его возможностей ALM.

gbjbaanb
источник
1
Спасибо, что поделились своим опытом, и это хорошо, чтобы получить некоторые негативы. Я использовал ClearCase некоторое время назад на предприятии, и это был худший SCM, который я когда-либо использовал. Административные накладные расходы связаны с тем, что мы небольшой стартап, но мне очень нравится, что наша текущая настройка практически не требует администрирования.
Сэм
Serena Dimensions был худшим, что я когда-либо использовал, по сравнению с Clearcase он не казался таким уж плохим, по крайней мере, это сработало! Я думаю, что MS хочет, чтобы вы использовали их облачную версию TFS. Самостоятельно установленную систему можно продавать корпорациям за большие деньги. Я бы придерживался того, что у вас есть. Получить еще несколько инструментов, чтобы дать вам ту же функциональность (например, ReviewBoard).
gbjbaanb
о, и я знаю, что это ошибка, поэтому ее не особо справедливо выделить, но если вы попробуете функцию проверки кода в TFS, и вы попытаетесь просмотреть файл, который был переименован и изменен, TFS сообщит о "предыдущем ошибка не найдена Если вы делаете много рефакторинга, это может быть проблемой. Это может быть небольшой ошибкой, но тогда это также может быть серьезной архитектурной проблемой, если они не отслеживают переименования файлов в внутреннем хранилище TFS.
gbjbaanb
2
Извините за поздний ответ, в конечном итоге вы отговорили меня от использования TFS. Спасибо.
Сэм
1
Приятно это слышать - кажется, все думают, что должны использовать TFS, тогда как на самом деле все мы должны использовать широкий спектр инструментов. В противном случае у нас останется всего 1 или 2 компании, которые предоставляют все наши ИТ-инструменты ... Microsoft и Oracle ... это не самый хороший мир для жизни :) Atlassian делает хорошие инструменты, больше людей должны оценивать их.
gbjbaanb
12

Я перешел из компании со стеком Atlassian (и Mercurial) в компанию с тяжелым стеком TFS. Я нахожу два раздражения.

Первым является Source Control .

Когда вы привыкли к DVCS, переключение обратно на CVCS является болезненным. TFS особенно болезненна, потому что для того, чтобы эта интеграция работала, она настаивает на постоянном подключении к серверу.

Однако, к счастью, Microsoft недавно разрешила интегрировать контроль версий Git в остальную часть стека TFS. Так что вам не нужно отказываться от Git, и я советую вам этого не делать, учитывая, что все это уже знают.

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

Другое раздражение - причина, по которой большинство людей не будет думать об уходе от TFS: интеграция с Visual Studio .

Мне еще предстоит выяснить когнитивные причины этого, но, по моему опыту (и принимая во внимание, что это обобщает), люди, которые привыкли к TFS, любят интеграцию. Они не любят выходить за пределы своей IDE ни за что.

Я, с другой стороны, не грелся к нему после года. Я нахожу это беспорядочным и трудным для навигации, по сравнению с тем, что мой сервер сборки находится на одной вкладке браузера, мои билеты на другой вкладке браузера и так далее. (Редактировать: как отмечает Андрей, есть веб-интерфейс, но он также необъяснимо неуклюж, когда вы привыкли к более свежим версиям Jira и Jenkins. Но, тем не менее, он по крайней мере работает сейчас в браузерах, отличных от IE. это что-то.)

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

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

Кроме того, не забывайте, что это 2 негатива, один из которых может быть личным, в довольно большой инфраструктуре. Большая часть моего опыта хороша, и TFS не так плох, как некоторые заставят вас поверить. И большинство вещей, которые вам не хватает, возможно, можно включить (это очень настраивается); учитывая, что вы перемещаете целую команду, а не одного человека, вы можете найти меньшее сопротивление.

прецизионный самописец
источник
1
Это в основном то, что я бы ответил. Рад знать, что я не единственный!
Саймон Уайтхед
1
Вы можете выполнить проверку кода для подтвержденного кода, но вы просто знаете, что можете предотвратить повторную регистрацию до тех пор, пока после проверки пользователи не будут использовать ее именно так. Корпоративные политики везде будут написаны, так что это обязательно, и тогда это станет еще одним узким местом процесса, чтобы разозлить разработчиков.
gbjbaanb
5

У меня очень положительный опыт использования TFS 2012. Настроить и запустить ваш сервер TFS довольно легко, автоматизация сборки CI очень проста и понятна (а сборка регистрации Gated просто потрясающая. Нам не удалось добиться такой же функциональности). с Team City). Командное взаимодействие очень прозрачное и прямолинейное. Вы можете легко связать свои регистрационные элементы с рабочими элементами TFS, управлять журналом ожидания, отслеживать дефекты, выполнять пересмотры кода и так далее. Есть даже встроенный мессенджер =)

Однако имейте в виду, что если вы привыкли к рабочему процессу JIRA, настройка рабочего процесса TFS может оказаться сложной задачей. Я бы предложил принять один из предопределенных рабочих процессов TFS. Также вам придется сохранять Confluence в качестве базы знаний или переходить на SharePoint, так как в TFS нет встроенной вики.

TFS намного дешевле, если у вас есть подписка MSDN (я полагаю, что большинство разработчиков, работающих с технологическим стеком MS, имеют ее), в этом случае у вас есть TFS бесплатно.

Я думаю, что нет причин продолжать использовать сторонние инструменты, если вы все ваши разработчики работаете с Visual Studio. TFS предоставляет интегрированную, надежную, но простую в использовании систему ALM. Я с удовольствием отвечу на ваши вопросы, если у вас есть какие-либо.

Андрей Зубов
источник
1
Большое спасибо за ваш отзыв. Мы используем BizSpark, который, я уверен, включает TFS. Я думаю, что единственное, что я хотел бы от вас, это какие-то негативы, просто взвесить. Я рад остаться с Confluence, так как я действительно не люблю SharePoint.
Сэм
Система уведомлений об изменениях в TFS несколько проще, чем в других решениях (например, Test Track имеет гораздо более надежную систему). В TFS вы получаете уведомления только в том случае, если вам присвоен рабочий элемент, например, вы не можете подписаться на изменения определенного рабочего элемента. Я думаю, что это не большая проблема в гибком рабочем процессе, но если вы сильно полагаетесь на уведомления в своем рабочем процессе, это может быть проблемой. Контроль источника потребует некоторого времени, чтобы привыкнуть. Особенно, если вы привыкли к командам командной строки GIT. Но я думаю, что визуализация ветвления стоит усилий.
Андрей Зубов
-3

Люди должны знать, TFS это не просто VCS, это ALM .

Кажется, многие люди просто хотят VCS, но пойти на TFS - неправильный путь.
Для CVCS я все еще предпочитаю SVN.
Для соло или с открытым исходным кодом, обязательно перейдите на GIT.

Но TFS2012 не плохой, его легко понять по слиянию / разветвлению, тогда SVN.
И услуга Team Foundation является бесплатной для 5 пользователей / неограниченное, частное репо.

Клиент также бесплатен, TFS Explorer построен на базе VS2010, и он бесплатный.
Для Eclipse у него есть плагин Eclipse - TFS везде.

Я не вижу никаких проблем с этим.
TFS Express (бесплатно) может работать с SQL Server Express (тоже бесплатно).

Cheung
источник
1
как это отвечает на заданный вопрос?
комнат