Какие преимущества имеет TFS 2010 перед Axosoft OnTime?

Question

В настоящее время я создаю экономическое обоснование для развертывания TFS 2010 в качестве инструмента управления версиями и управления ошибками / выпусками.

В настоящее время мы используем OnTime для нашего программного обеспечения для отслеживания ошибок и Subversion для нашего SCM.

Мне было интересно, какие преимущества имеет TFS 2010 перед OnTime?

Я немного подумал и хотел бы услышать ответы:

• TFS 2010 позволяет связывать наборы изменений-> рабочие элементы-> сборки
• TFS 2010 обеспечивает большую настройку рабочего процесса, чем OnTime
• TFS 2010 интегрирован в Visual Studio IDE - для этого требуется меньше приложений для открытия и меньше щелчков окна

Заранее спасибо.

Answer 1

TFS - одна из наименее интуитивно понятных систем контроля версий, с которыми мне когда-либо приходилось сталкиваться. Он может иметь многочисленные преимущества «пули» по сравнению с OnTime (и другими сопоставимыми системами) с точки зрения необработанных списков функций и возможностей, но ключевым фактором является возможность его соответствия вашим рабочим процессам.

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

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

В итоге мы решили продолжить использовать SVN, но кардинально пересмотрели (упростили) структуру нашего хранилища и решили объединить SVN с системой отслеживания ошибок FogBugz. Интеграция между этими двумя системами была довольно элементарной «из коробки», но с нашей стороны потребовалось лишь небольшое усилие для достижения гораздо более близкого уровня интеграции, который мы желали. Конечно, гораздо меньше усилий, чем мой предыдущий опыт развертывания TFS .

Наша система SVN / FogBugz теперь также интегрирована с комплектом автоматизации сборки FinalBuilder.

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

Answer 2

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

Я использовал bugzilla в сочетании с Perforce в течение нескольких лет и обнаружил, что оба очень хорошо разбирались в своих собственных вещах, работая в очень небольшой команде (2-3 человека), но страдали от отсутствия интеграции между ними и какими-то маленькими идиосинкразиями, к которым потребовалось время, чтобы привыкнуть.

Недавно я перешел на новую работу, где TFS широко используется. В этой компании 4 основные команды с 10-12 разработчиками в каждой, разделенные на дальнейшие проектные команды ниже этого уровня, и именно в такой среде TFS действительно блестяще выглядит. На мой взгляд, это самые большие преимущества:

1) Интеграция с Visual Studio - это не просто случай открытия меньшего количества окон, но действительно ускорение и упрощение вашей жизни. Такие вещи, как VS, автоматически проверяют файлы для вас во время работы (нет проблем со случайными извлечениями из-за редактирования без блокировки), имеют возможность синхронизировать локальные сборки + TFs, возможность быстрого сравнения локальной версии с предыдущими ... да, вы можете получить Сторонние плагины для интеграции, но не для этого уровня и с той же стабильностью.

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

3) Связывание сборок / списков изменений с задачами - да, другие SCM делают это, но опять же, это просто сделано очень хорошо, интегрированным образом ... Я думаю, что это ничего особенного для TFS, но лично мне нравится, как это отслеживается.

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

5) Автоматическое построение / управление сборкой. Работа с парой крупных решений, содержащих 20-30 проектов, которые зависят друг от друга, - это находка. Он настроен на постановку в очередь сборки каждые 20 минут, если что-то изменилось, и когда это произошло, оно занесено в журнал истории ... так легко увидеть, когда вам нужно обновить ваши локальные библиотеки.

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

Итак, переводя это на экономическое обоснование ... Я бы сказал, что если вы являетесь разработчиком программного обеспечения Microsoft с большой / несколькими группами, то экономия времени и повышение производительности, которые вы увидите в результате использования вышеуказанных функций, стоит инвестиций в его настройку. Его можно использовать в большинстве случаев, так как у вас, вероятно, будет подписка MSDN (возможно, некоторые проблемы с клиентскими лицензиями, но я не уверен), поэтому ваши самые большие затраты будут на обучение пользователей и настройку.

Answer 3

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

С точки зрения v ersion control Я бы порекомендовал пост в блоге Мартина Фаулера о Инструментах контроля версий и последующих результатах опроса систем контроля версий . По общему признанию это может быть и является субъективным взглядом на предмет, но тот, который кажется довольно популярным. TFS явно проигрывает по сравнению с другими системами контроля версий.

В настоящее время я работаю с TFS2008, и мы перешли с SourceSafe и IBM ClearCase / ClearQuest, и нет никаких сомнений в том, что TFS намного лучше, чем любой из предыдущих инструментов, тем не менее, он имеет свои серьезные недостатки, и новая версия будет устранять только частично те.

Обращаясь к поднятому вами индивидуальному вопросу:

• TFS позволяет связывать сборки с наборами изменений и рабочими элементами, но во многих других системах
• Я не использовал OnTime, но настройка рабочего процесса может быть как преимуществом, так и помехой. Потенциально, может потребоваться много работы для создания пользовательского шаблона процесса , и вам все равно понадобится разумный пользовательский интерфейс поверх него (Team Explorer или Web Access может быть недостаточно)
• Интеграция с Visual Studio является преимуществом, но в Visual Studio есть надстройки, которые позволяют интеграцию с другими поставщиками управления исходным кодом

О преимуществах TFS я бы, наверное, упомянул

• Распределенные сборки и отдельные агенты сборки - если вы делаете много сборок
• Полная интеграция с Visual Studio через Team Explorer
• Обширная инфраструктура отчетности (хотя вы можете в полной мере использовать ее при использовании MSTest для всех испытаний)
• Сайт совместной работы SharePoint для каждого проекта

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

Answer 4

Не уверен насчет TFS, но пользовательский интерфейс OnTime не интуитивно понятен. Также мне не нравится, что у вас есть разные поля для ошибок и задач. Конечно, вы всегда можете добавить свои собственные поля, но макет по умолчанию должен быть готов к использованию.

Мы используем только "ошибки", даже если это задача.

Я не говорю, что это плохой продукт, но если TFS имеет лучший пользовательский интерфейс для отслеживания ошибок сейчас (которого он не имел 4 года назад, когда мне приходилось его использовать и ненавидел), то это будет аргументом для TFS.

Жаль слышать, что вы хотите избавиться от SVN. Это трудное решение.

Answer 5

Я не уверен насчет лицензирования Axios OnTime, но если у вас есть подписка MSDN, это не требует дополнительных затрат.Смотрите сообщение в блоге здесь

Я использую TFS 2008 только для контроля версий, и хотя это хорошее обновление от VSS, некоторые вещи, которые мы пытаемся сделать, не совсемлиния с тем, что ожидается.Тем не менее, я написал небольшое веб-приложение, которое заполняет эти пробелы.Это было довольно легко разработать против использования API, и есть много дополнений, которые помогут с конкретными задачами.

Answer 6

Пока избегайте TFS!

Я бы выбрал SVN + FinalBuilder, а затем выбрал FogBugz или CounterSoft Gemini.

Answer 7

Я бы настоятельно рекомендовал против TFS.Однажды я попытался восстановить исходный код из аварийного экземпляра, но через несколько дней сдался, поэтому исходный код был потерян (= он не смог сделать то, что должен делать VCS).Конечно, я мог бы сделать что-то не так, но все не так просто сделать правильно, когда руководство по восстановлению имеет длину две мили, и это действительно должно случаться так редко, что никто не сталкивается с этим.

Теперь я использую Subversion / Trac, которая выполняет свою работу (а настроить рабочий процесс в Trac так просто, что это не весело, по сравнению с TFS).

Answer 8

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

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

Я использовал OnTime и Subversion. Я не использовал TFS как средство отслеживания ошибок, но я использовал его для контроля версий. Часть управления исходным кодом в основном все еще является плохим старым Visual SourceSafe. Если вы в настоящее время используете Subversion, вы будете ругаться головой в любое время, когда вам нужно переименовать файл или, боже упаси, удалить файл и затем создать его с тем же именем - не говоря уже о ветвлении или слиянии. В посте трудно передать, насколько она примитивна и хрупка как система контроля версий, поэтому вам действительно нужно ее использовать. Вы поймете, что я имею в виду, когда обнаружите, что застряли в файле, который вы не можете ни проверить, ни удалить, ни какую-нибудь бессмысленную ошибку. Не то, чтобы Subversion идеален - но VSS на десять лет вперед!

Часть рабочего процесса TFS, с которой я только коротко играл, кажется мне очень «тяжелой». То есть он действительно ограничивает пользователя этим рабочим процессом и требует много шагов, которые часто не нужны. Этот материал может помочь, но он также может легко мешать. Хорошая система обеспечивает рабочий процесс, когда это необходимо, но позволяет вам обойти его, когда он только мешает. Когда мы использовали OnTime, мы обнаружили, что даже его относительно ненавязчивый рабочий процесс часто был просто большим количеством проблем, чем он того стоил. Конечно, все зависит от специфики вашей ситуации. Как вы используете рабочие процессы OnTime сейчас и что вы хотите от TFS, которую не обеспечивает OnTime?

Связывание наборов изменений с ошибками также может быть сделано с помощью Subversion. Он поддерживает некоторый механизм расширяемости - я не помню деталей, но FogBugz использует его (мы переключились на него после OnTime). Связать со сборками можно, добавив простую команду svn tag в ваш скрипт сборки. Интеграция Visual Studio может быть сделана с VisualSVN .

Стоимость также является огромным недостатком TFS. Это очень дорого за то, что он делает, особенно если принять во внимание, насколько хорошо это делает. Да, это «бесплатно» , если вы все равно должны иметь подписку MSDN для каждого разработчика - но вам нужно без TFS? Subversion бесплатная, полная остановка. OnTime и FogBugz гораздо дешевле.