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

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

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

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

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

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

Небольшой опрос Мартина Фаулера много говорит о состоянии 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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