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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Большинство любого популярного дефекта/выпуск систем слежения будет обрабатывать управление инцидентами и документа - думают, вики с ПРОФАМИ или FogBugz (по с SVN для дока Упра)

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

Answer 7

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

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

Также рассмотрите Сейф или Крепость от SourceGear, так как они предназначены для людей, которые используются для Visual SourceSafe, например. они имеют закрепление.

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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

Answer 11

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

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

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

управление Release (строения и развертывание)
Hudson

инцидентам и проблема управления
Trac

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

анализа кода ограничения на проверки (вопросы и ошибки) -ins
Coverity

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

Отчетность
StatSVN

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

Answer 12

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

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

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

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

Answer 13

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

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

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

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