Team Foundation Build или TeamCity?

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

Мы начинаем нашу инициативу по внедрению TDD во всей команде (~ дюжина ppl). У меня есть настройка 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...

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

EDIT: Кто-нибудь использовал TFS в качестве своего сервера Build/CI и может рассказывать об истории успеха/неудачи?

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

Надеюсь, что поможет

Ответ 3

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

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

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

Ответ 4

Во-первых, см. это сообщение:

SVN и Team Foundation Server

Что касается вашего вопроса о том, какая среда лучше способствует 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. Также не было достаточного обоснования дополнительной стоимости лицензии для TLS, которая может быть значительной.

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

MS отстает от года в области TDD/CI

Будучи тем, у кого TDD'd в течение 4 лет, вы правы. MS по-прежнему не продвигает его и не предлагает инструменты, которые хорошо работают с потоком TDD.

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

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

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

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

Остановите попытку полагаться на продолжающийся сбой Microsoft при использовании гибких инструментов

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