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

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ваше понятие отчетности нечеткое, но я думаю, что у вас более чем достаточно инструментов в любом сценарии для удовлетворения этого

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

(Думаю, вы ответили на свой вопрос.) Это может стать религиозной войной между MS и анти-MS сторонами.

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

Сказав это, вот некоторые другие варианты:

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

Хотя вопрос, я думаю, оба пути имеют свои достоинства. Мне очень нравится удобство базовых и ежедневных операций, которые TFS обеспечивает благодаря интеграции с Visual Studio. GUI'wise, если вы сравните его с TortoiseSVN, он действительно потеряет функцию. У TFS есть утилита командной строки, которая охватывает большинство функций, отсутствующих в графическом интерфейсе. Помимо управления версиями, я думаю, что TFS обеспечивает гораздо более сильное сцепление, когда дело доходит до установки политик регистрации/фиксации, связывания их с рабочими элементами и т.д. Мне нравится веб-интерфейс, в частности, что TFS предоставляет (хотя и изучать его модель лицензирования, прежде чем получить чрезмерно восторженные) Совмещение конфликтов конфликтов довольно неудовлетворительное в VS2008, что улучшится в VS2010. TFS - это, как правило, домкрат всех профессий, возможно, освоение не. Однако TFS также позволяет использовать гибридные решения для непрерывной интеграции, а также различные инструменты из того, что вы называете "стек Subversion", в сочетании с TFS.

Ответ 11

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

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

Ответ 12

Наш стек выглядит следующим образом:

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

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

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

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

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

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

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

Отчетность
StatSVN

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

Ответ 13

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

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

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

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