Является ли «стек» Subversion реалистичной альтернативой Team Foundation Server?

Question

Я оцениваю Microsoft Team Foundation Server для своего клиента, который в настоящее время использует Visual SourceSafe и ничего больше. Они явно выразили желание реализовать более жесткую и управляемую процессами среду, поскольку их приложение находится в производстве, и у них есть будущие выпуски для рассмотрения.

Конкретные области, которые я пытаюсь охватить:

• Управление конфигурацией (например, контроль источника)
• Управление изменениями (рабочий процесс и документация для запросов на изменение, задач)
• Управление релизами (сборками и развертывание)
• Управление инцидентами и проблемами (проблемы и ошибки)
• Управление документами (аналогично контроль источника, но доступен через Интернет)
• Ограничения анализа кода при регистрации
• Среда тестирования
• Отчетность
• Интеграция Visual Studio 2008

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

Эти проблемы можно преодолеть, но прежде чем я скажу своему клиенту идти по пути TFS, что само по себе не страшно, я хотел оценить альтернативы. Я знаю, что Subversion часто предлагается для управления конфигурацией / контроля исходного кода, но как насчет других областей? Будет ли комбинация Subversion / NUnit / Wiki / CruiseControl / NAnt / что-то еще удовлетворить все эти требования? Какие инструменты мне нужно включить в мою оценку?

Или я должен просто прикусить пулю и перейти на TFS, поскольку мы уже вложены в стек Microsoft?

Answer 1

Некоторые очень крупные проекты успешно работают на SVN или GIT.

Я бы предпочел использовать разные лучшие в своем классе приложения, которые общаются друг с другом, чем одно монолитное создание, такое как TFS. Многие бесплатные и коммерческие баг-трекеры интегрируются с SVN, как и тест-бегуны. Как правило, проще создавать собственные интерфейсы для чего-то вроде SVN, чем заставлять приложение MS-сервера делать что-то новое.
И, наконец, легче перейти от чего-то вроде SVN к следующему замечательному новшеству, чем получить данные из проприетарного пакета, такого как TFS.

Answer 2

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

Я профессионал SVN. (Но TFS будет работать, я уверен)

Я бы предложил очень легкое вторжение в повседневные задачи.

Наличие песочниц или правил продвижения из одной ветки в другую в SVN - один из способов анализа кода без задержки процесса фиксации.

Итак, для решения каждого из ваших пунктов: SVN управляет контролем версий и является вспомогательным / входит в управление изменениями и управление релизами

Управление изменениями / рабочий процесс в основном определяется проектной командой и может быть полезен с помощью простых инструментов или просто обеспечивается политикой.

Управление релизами также основано на политике и использует существующую инфраструктуру / инструменты (SVN)

Большинство любых популярных систем отслеживания дефектов / проблем будут обрабатывать управление инцидентами и документами - например, вики с trac или fogbugz (вместе с SVN для doc mgmt)

FXCop и все остальные инструменты могут быть частью сборки для анализа кода

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

Ваше представление о сообщениях расплывчато, но я думаю, что у вас более чем достаточно инструментов в любом сценарии, чтобы удовлетворить это

Я не уверен, что вам действительно нужно для интеграции с 2008 годом. В любом случае это не так тесно, как TFS, но я не вижу в этом проблемы.

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

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

Что касается инструментов, которые нужно учитывать - я думаю, что поиск переполнения стека для nant, msbuild, cruisecontrol и т. Д. Даст вам больше контента, чем вы можете потрясти ...

Answer 3

Я думаю, что следующий стек превосходит TFS:

• Сервер VisualSVN - контроль источника
• Jenkins - автоматизированная сборка
• Redmine - отслеживание проблем

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

Answer 4

Если целевые разработчики ориентированы на Microsoft, а клиенту нужен принудительный процесс, то оставаться в TFS - хороший вызов. Затраты на внедрение должны принимать во внимание кривую обучения, любую потерю производительности и существующую инфраструктуру. Если это большой магазин, и он звучит так, как он есть, вам также понадобится вступительный взнос ИТ-команды, который может быть трудно получить с помощью целого стека новых технологий.

Сказав это, вот еще несколько вариантов:

Возможно, вы захотите взглянуть на Subversion + Jira Atlassian * (1006 *) (отслеживание проблем), Confluence (вики), Bamboo (CI), Clover (покрытие кода), Fisheye (репозиторий "Insight" )

Это коммерческие инструменты, но они уже интегрированы и хорошо интегрируются с Subversion.

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

И, наконец, есть Диспетчер изменений программного обеспечения от Computer Associate , который обеспечивает самое неприятное принудительное выполнение процессов из всех инструментов, которые мне когда-либо приходилось использовать. Но если вам нужен анально-настойчивый, обсессивно-компульсивный обязательный процесс, это инструмент для вас.

Answer 5

Я удивлен, что никто не упомянул Collabnet's TeamForge . Это стековая часть SVN для отслеживания ошибок и других средств управления поверх SVN.

Он не обеспечивает управление требованиями, как и другие приложения (например, Требования Polarion ), но если вы можете отследить требование как «ошибку», тогда все будет хорошо.

Кстати, у Polarion есть ALM , который является конкурентом TFS - у них есть сравнительная таблица на сайте. Дорого, хотя: (

Лучшей бесплатной альтернативой, вероятно, будет Redmine ИМХО.

Answer 6

Я хотел бы взглянуть на SVN, Trac, CruiseControl и Nant ... все бесплатно, с открытым исходным кодом, и чрезвычайно зрелый.

Я убедил свое рабочее место в этом стеке и не оглядывался назад ...

Answer 7

Team Foundation Server также включает управление сборкой, управление сборкой TFS можно использовать для Непрерывная интеграция , а также выпускные сборки и т. Д.

Я использовал CruiseControl.NET с Subversion для управления сборкой, и это сработало. Однако TFS даст вам больше контроля и аудита и т. Д. Подумайте, хотите ли вы иметь такой уровень контроля над вашим программистом или вам следует доверять им больше.

Также рассмотрите Vault или Fortress из SourceGear , так как они предназначены для людей, привыкших к Visual SourceSafe, например,. у них есть пиннинг.

Answer 8

Я работал с обеих сторон забора. Первоначально я был вынужден использовать SourceSafe. Я ненавидел это со страстью. Когда я был в состоянии управлять ИТ-политикой, я попробовал несколько разных вариантов и пошел по пути SVN и Trac. Это было не без кривой обучения, но результаты были великолепны.

Затем я начал работать в довольно большом месте, где используются SourceSafe и RedMine. Я в основном пропустил SVN, но мне понравился Redmine.

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

Из этих вариантов, SVN и Jira будут предпочтительной комбинацией. SourceSafe будет в нижней части списка, за ним будет очень внимательно следовать TFS.

Answer 9

Наш стек выглядит так:

Управление конфигурацией (например, контроль источника)
SVN

Управление изменениями (рабочий процесс и документация для запросов на изменения, задач)
Trac

Управление релизами (сборки и развертывания)
Hudson

Управление инцидентами и проблемами (проблемы и ошибки)
Trac

Управление документами (аналогично управлению источниками, но доступно через Интернет)
SVN (с Apache для веб-интерфейса)

Ограничения анализа кода при регистрации
Coverity

Среда тестирования
Hudson (поддерживает множество различных структур модульного тестирования)

Отчетность
StatSVN

Интеграция Visual Studio 2008
VisualSVN

Answer 10

VisualSVN обеспечивает действительно хорошую интеграцию между SVN и VS. мы мигрировали из TFS в SVN. тогда (около 2 лет назад я думаю ...) мы почувствовали, что TFS раздутый и медленнее (намного медленнее по сравнению с svn). Но я уверен, что к настоящему времени все должно было улучшиться.

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