Эффективен ли TFS для больших команд, а SVN - для небольших?

Question

Я и с открытым исходным кодом и любитель SVN. Мы в компании находимся в ситуации, которая должна определиться между SVN или Team Foundation Server. Я пытаюсь убедить других использовать SVN, потому что я думаю, что TFS улучшена в больших командах. Мы всего лишь 7 разработчиков и 3 тестировщика. Я прав насчет этого?

Answer 1

Почему вы думаете, что TFS - это большая система?

У меня он установлен на моем ноутбуке с Windows 7 с использованием SQL Express, и я даже не замечаю его там. С TFS2010 вы можете отказаться от установки Sharepoint, Reportign Services и интеграции служб Analysis с самого начала. Вместо этого вы можете просто управлять версиями, отслеживать рабочие элементы (ошибки, тесты, проблемы, задачи и пользовательские истории) и автоматизировать сборку.

Фактически я установил и настроил все это менее чем за 20 минут, и в моем последнем проекте потребовалось около 30 минут для настройки нового продукта со всеми этими вещами.

Зачем вам использовать TFS?

1. Дешево (бесплатно для всех подписчиков MSDN и $ 400 в розницу с 5 пользователями)
2. Быстрая установка
3. Быстрая настройка
4. Простота в использовании
5. Много документации
6. Поддержка всего от одного поставщика

Если вас устраивает то, что предлагает TFS с базовой установкой, вы можете добавить Lab Management, если вам нужно автоматическое тестирование среды или службы анализа, если вам нужно больше отчетов.

Answer 2

Сравнение SVN с TFS похоже на сравнение яблок и апельсинов. SVN - это система контроля версий, в то время как TFS - платформа ALM, как уже упоминали другие.

Предположим, что компания выбирает Subversion, CruiseControl.NET, какой-то инструмент управления Agile Project, средство отслеживания ошибок (Bugtracker.NET, Bugzilla, ...). Давайте предположим, что все инструменты, которые выбирает эта компания, это OSS, можно подумать, что это бесплатно, верно? К сожалению, вам все равно нужно будет начать интеграцию всех этих инструментов, и именно здесь реальные затраты.

Конечно, такая платформа, как Team Foundation Server, требует затрат на лицензирование и предлагает то же, что и все ранее упомянутые инструменты OSS, но уже хорошо интегрирована.

Таким образом, если вам нужны инструменты для поддержки вашего ALM и вы ориентированы на Microsoft, вам следует серьезно рассмотреть вариант TFS. Конечно, как технический специалист, интересно выяснить, как интегрировать Bugzilla с Subversion и инструментом управления проектами, и провести ночи, пытаясь выяснить, как мы экспортируем / импортируем все эти даты в специально разработанный инструмент отчетности, специально разработанный для отдел кадров за отчетами по отслеживанию времени и так далее. Вы понимаете, о чем я.

В конце концов альтернативный путь OSS стоит намного дороже, чем путь TFS, и люди просто не хотят его признавать, с другой стороны, если, конечно, вам нужна только система контроля версий, которая вам не нужна TFS. Но если это все, что вам нужно как разработчику, можете ли вы назвать себя серьезным разработчиком? ; -)

Answer 3

Я не уверен, что между ними есть какая-то внутренняя разница (в отношении размера команды). Мне известны большие различия:

1. TFS предоставляет дополнительные функции, такие как отслеживание ошибок и «Team Build», помимо простого контроля версий.
2. Все функции TFS хорошо интегрированы в Visual Studio IDE.
3. Лицензионные расходы.

Answer 4

Ну, TFS - это гораздо больше, чем просто контроль версий. Если вы ищете только контроль версий, TFS слишком дорогой. ПО МОЕМУ МНЕНИЮ. Я бы придерживался SVN. Однако, если вы ищете такие вещи, как набор тестов, управление проблемами и т. Д., Я бы посмотрел на TFS.

Answer 5

+ 2 цента.

TFS не только предоставляет вам контроль исходного кода + отслеживание рабочих элементов (ошибки, тесты, проблемы, задачи и пользовательские истории) + автоматизированное построение, вы также получаете ОЧЕНЬ БОЛЬШУЮ И ВПЕЧАТЛЯЮЩУЮ базу данных анализа, в которой вы можете получать информацию из этих различных данных. источники, без дополнительной работы. Я имею в виду, вы можете понять, почему в конкретной сборке есть некоторые ошибки, связанные с указанными файлами, которые были проверены, связанные с заданиями / ошибками, связанными с файлами, связанными с пользовательской историей, связанной с задачей, и т. Д. Без дополнительных усилий вы можете получить более подробное представление о том, что происходит в проекте разработки.

Answer 6

Я видел, как SVN успешно использовался в очень больших командах, когда его поддерживали такие вещи, как серверы автоматической сборки. Если вы пытаетесь убедить других использовать SVN, вам, вероятно, лучше просто указать 3 причины, по которым вы любите SVN, которых нет в TFS, и почему вы чувствуете, что они важны, чем пытаться сказать, что один из них «более эффективен «

Answer 7

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

Таким образом, каждые несколько лет вы должны выбрасывать все и начинать все заново - поскольку в TFS нет встроенного способа экспортировать все, что вы сделали. Когда вы строите новую систему - вы не можете переместить все элементы истории работы и т. Д., Только думайте, что можете это сделать, просто переместите свой код ВРУЧНУЮ в новую систему и заново создайте все заново.

Отличный способ тратить недельную работу на каждый проект, который вам нужно переместить.