Team Foundation Build или TeamCity?

Question

В основном мы работаем в магазине MS и занимаемся разработкой .NET LOB.Мы также используем MS Dynamics для нашего приложения CRM...все разработчики в настоящее время используют VS/SQL Server 2008.Мы также используем VSS, но на работе его ненавидят все, и он быстро уходит из жизни.

Мы начинаем нашу инициативу по внедрению TDD во всей команде (~ дюжина человек).Я установил TeamCity, и мои первые автоматические сборки успешно выполняются с использованием компоновщика sln 2008 года, а также с использованием SVN, который настроил мой коллега, который выполняет анализ системы управления версиями.Я думаю, что во время демонстрации руководству они начали покупать мою змеиную нефть и отказались от предложений изучить TFS.

Это нарушило мои планы относительно нашей TDD-архитектуры;В хорошем смысле, потому что я всегда считал, что TFS слишком дорога и не стоит того для нашей команды (и я видел то же самое в других магазинах, в которых я работал/о которых знаю).Я чувствую, что MS на несколько лет отстает в области TDD/CI и что продукты сторонних производителей, вероятно, были намного лучше и более зрелыми...Мне еще нужно провести много исследований, но я решил прийти сюда, чтобы узнать, использовал ли кто-нибудь обе системы.

Я понимаю, что TFS включает в себя гораздо больше, чем просто сервер сборки...но я не хотел, по крайней мере намеренно, задавать этот вопрос слишком широко. Каковы практические плюсы и минусы использования TFS/TFB вместо TeamCity?какие преимущества мы потеряем/получим?Кто-нибудь здесь действительно использовал обе системы (TFS для TDD/CI и TeamCity/SVN) и может говорить с практической точки зрения?

Я немного поискал по этой теме, и в одном сообщении, которое я нашел здесь, на SO, упоминалось, что минусами TFB является то, что он поддерживает только MSBuild.Я планировал использовать FinalBuilder с TeamCity;и, похоже, он также поддерживает TFS...

Спасибо за любой совет

РЕДАКТИРОВАТЬ:Кто-нибудь использовал TFS в качестве сервера сборки/CI и может рассказать истории успеха/неудач?

Answer 1

Мы — небольшая компания, занимающаяся разработкой, и решили, что Team Foundation Server несет для нас слишком много накладных расходов.Раньше мы писали собственные сценарии MSBuild для запуска из командной строки, но после того, как мы открыли TeamCity, мы перенесли на него весь процесс сборки.

Мы обнаружили, что TeamCity прост в использовании и настройке, а JetBrains предоставляет отличную поддержку и документацию.Они также находятся в гораздо более быстром цикле выпуска и обновления, чем Microsoft.

Их поддержка системы управления исходным кодом SVN превосходна, и нам нравится тот факт, что они поддерживают как MSTest, так и NUnit для модульного тестирования.

Нам также понравилось то, что версия TeamCity Professional была бесплатной, поэтому мы могли оценить ее и убедиться, подходит ли она нам.Мы еще не достигли количества конфигураций проекта (20), которые потребовали бы обновления до версии Enterprise.

Answer 2

Этот вопрос есть много хороших ответов о TeamCity.Его нельзя сравнивать с TFS, но он может пролить свет на TeamCity.

Я использовал оба варианта и добился успеха с обоими, но TeamCity оказался намного проще.TeamCity было легко установить и настроить.ТФС не было.TeamCity надежен, его легко поддерживать, и он просто работает.Разработчики JetBrains проделали огромную работу, реагируя на запросы сообщества.Они выпускают релиз каждые 6–8 месяцев, что добавляет реальную ценность.TFS находится на 2-летнем или более цикле.

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

Я прошёл 3 абсолютно безболезненных обновления в TeamCity.Единственное обновление TFS, которое мы сделали, привело к отключению системы контроля сборки и исходного кода на 3 дня.Я администратор TeamCity в нашем проекте, и это занимает пару часов в месяц.TFS занимал пару дней в неделю.

TeamCity + SVN + VisualSVN — самая удобная среда, в которой я когда-либо работал.TFS в целом работала бесперебойно изо дня в день, но только в том случае, если кто-то поддерживал ее работу.

надеюсь, это поможет

Answer 3

Преимущества TFS заключаются в единой интегрированной среде, поддерживаемой Microsoft.Лично мне не нравится TFS для контроля версий, и у меня было с ним ряд проблем.Он неуклюж, однако его преимуществом является интеграция с VS (которая также доступна в VisualSVN, но не так надежна).

Лично я думаю, что вам будет гораздо лучше использовать SVN/TeamCity.С ним просто легче работать, и он ведет себя так, как вы ожидаете.Как и большинство программного обеспечения с открытым исходным кодом, они оба постоянно развиваются и всегда будут иметь новейшие и лучшие функции, предшествующие Microsoft.Интеграция между ними действительно хороша, и я не нашел в системе никаких фатальных недостатков.Я постоянно настаиваю на том, чтобы идти по этому пути в моей нынешней компании (мы используем TFS), поскольку считаю, что это гораздо лучший рабочий процесс.Дополнительным преимуществом является то, что это значительно дешевле, чем использование TFS.

Я также использовал FinalBuilder с TFS. Мой вопрос: что вы на самом деле покупаете с FinalBuilder и чего не можете сделать с NANT/MSBuild?Ответ в моем магазине, к сожалению, очень маленький, по моему мнению.

Answer 4

Прежде всего, посмотрите этот пост:

СВН против.Сервер Team Foundation

Что касается вашего вопроса о том, какая среда лучше поддерживает TDD и тому подобное, мои два цента заключаются в том, что система управления сборкой имеет гораздо меньшее значение, чем то, что находится в самом файле сборки.В вашем файле Ant или MSBuild должны быть цели, на которых вы проводите тестирование.При использовании MSBuild или Ant вам не нужно использовать набор тестов MS.Вы по-прежнему можете использовать nUnit или что-то еще, что захотите.Это означает, что не имеет значения, вызывает ли TFS ваш файл MSBuild, CruiseControl или TeamCity.Все преимущества заключены в файле сборки и инструментах, которые вы с ним интегрируете.

Мой личный выбор — не привязываться к способу ведения дел TFS, поскольку у вас есть гораздо больше свободы за гораздо меньшие затраты с помощью богатых инструментов тестирования с открытым исходным кодом, которые существуют.TFS также скоро получит серьезное обновление.Если вы собираетесь использовать TFS, я советую хотя бы подождать до выхода 2010 года.Сосредоточьтесь на том, чтобы сделать ваши файлы MSBuild настолько хорошими, насколько это возможно, прямо сейчас.

При этом я должен признать, что TFS имеет одну из лучших систем сборки (2005 год был ужасен, 2008 год был хорош).Возможность легко настраивать уведомления и процесс выпуска внутри кода .NET была довольно крутой — у вас было гораздо больше централизованного контроля над политикой сборки и выпуска, чем у нас с CruiseControl.NET.

Итак, я использовал TFS и SVN/CCNet.Я не могу много говорить с TeamCity.Но, по моему мнению, система управления сборкой должна быть достаточно независимой от того, что и как создается.Для нас дополнительный контроль над процессом управления выпусками, который предоставил нам TFS, был недостаточным бонусом, чтобы оправдать значительно возросшие административные усилия полностью интегрированного решения TFS.Этого также было недостаточно, чтобы оправдать дополнительную стоимость одной лицензии TFS, которая может быть значительной.

Answer 5

Старая сборка TFS была основана на XAML, была очень громоздкой и с ней было неудобно работать.Тем не менее, новая система сборки TFS 2015 значительно лучше и основана на сценариях с множеством веб-перехватчиков и сторонних интеграций;очень похоже на Team City.Кроме того, TFS теперь поддерживает Git, поэтому вы больше не ограничены использованием контроля версий Team Foundation (TFVC).Кроме того, с помощью TFS вы можете использовать собственную локальную установку или воспользоваться преимуществами размещенного решения через Visualstudio.com.TFS великолепен, потому что это одна полностью интегрированная среда (рабочие элементы, планирование, сборки, тесты, развертывания), тогда как Team City — это просто решение для сборки.Когда этот вопрос впервые был задан в 2010 году, я бы без сомнений рекомендовал Team City.Однако сейчас эти двое очень конкурентоспособны.Я бы сказал, что, возможно, все сводится к тому, что если вам нужно универсальное решение, то используйте TFS, но если вы ищете просто систему сборки, то Team City.

Answer 6

Сравнение TeamCity с Visual Studio Team Services (последнее облачное предложение от Microsoft):

• Оба отлично подходят для реализации процесса непрерывной интеграции.

• TeamCity более зрелый, и все работает.

• Visual Studio Team Services, напротив, постоянно развивается, чтобы догнать TeamCity, и некоторые вещи просто не работают должным образом (например,попробуйте запускать сборки на основе путей, в которых есть изменения из Git - документация слабая, а сама функция просто не работает (по состоянию на август 2016 г.))

• Visual Studio Team Services позволяет легко запускать сборку только облачными агентами (однако недостатком является то, что каждый из них должен выполнять чистую выборку вашего репозитория для каждой сборки, что может добавить к сборке минуту или больше).Оба также могут поддерживать локальные агенты сборки, которым не нужно стирать рабочий каталог для каждой новой сборки.

Но в любом случае я настоятельно рекомендую вам также взглянуть на CakeBuild, который перемещает большую часть информации о конфигурации как выполнить сборку из системы CI в код C#, который находится в вашем репозитории Git вместе со всем остальным исходным кодом.С помощью CakeBuild вы можете запустить ту же сборку локально, что и в системе CI, и если вам нужно вернуться на месяц назад, чтобы собрать конкретную версию, у вас есть исходный код и сценарий сборки, чтобы сделать это.

Благодаря CakeBuild вы теперь можете легко переключаться между TeamCity и Visual Studio Team Services.

Единственным недостатком CakeBuild является то, что все этапы сборки объединены в одну задачу в системе CI, что делает отчетность немного менее удобной и может потребовать некоторой дополнительной работы для перевода результатов тестирования в формат, который может использовать система отчетов CI.

Answer 7

MS на несколько лет отстает в области TDD/CI

Поскольку вы пользуетесь TDD уже 4 года, вы правы.MS до сих пор даже не продвигает его и не предлагает инструментов, которые хорошо работают с потоком TDD.

Не зацикливайтесь на Visual Studio для любого вида автоматизации, контроля версий или гибкого рабочего процесса (пожалуйста, прекратите использовать TFS!!).Этот материал, хотя он и называется «новым», является монолитным и всегда сопровождается странными проблемами и раздутием.Это всегда больно.

Я использовал Team City, и он просто потрясающий, все работает, он создан для удобства использования, просто хорошо спроектирован и совместим с большинством всех инструментов тестирования и т. д.Хорошо, используйте Visual Studio для кода и ничего больше.Ищите внешние инструменты с открытым исходным кодом, которые помогут улучшить CI.Продвижение «в VS можно делать все правильно» не является продажей и не работает.Сегодня люди привыкли и всегда комбинируют различные внешние инструменты для достижения цели.Полагаться на все наборы инструментов MS - это не лучший вариант, по моему мнению, для .NET.MS любит продавать: «Эй, ты можешь делать все прямо здесь».Но в итоге вы не получите ничего, кроме боли, если пойдете по этому пути и выпьете их куладу (TFS, MS Fakes и т. д.).

Если вы планируете использовать TDD, вам определенно не стоит использовать все инструменты MS.Вам либо придется отказаться от «их способа» делать вещи, которые часто являются проприетарными и/или раздутыми, когда вы попытаетесь использовать TDD с их инструментами, либо вы будете полностью ограничительны.Для TDD вам нужна определенная гибкость и выбор, когда вы решите использовать различные тестовые среды, библиотеки утверждений и т. д.

Добавлять Осьминог поверх Team City, и это великолепно... вы просто влюбитесь в него как разработчик или любой, кто занимается DevOps.

Перестаньте полагаться на постоянные неудачи Microsoft в предложениях гибких инструментов

Начните смотреть нестандартно и пробовать что-то новое — это то, что я постоянно повторяю миру .NET, поскольку в прошлом я был разработчиком .NET и пробовал новые вещи за пределами мира MS.