Team Foundation Build или TeamCity?

Question

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

Мы начинаем нашу инициативу по внедрению TDD во всей команде (~ дюжина человек). Я получил настройку TeamCity, и мои первые автоматические сборки были успешно запущены с использованием сборщика 2008 sln, а также с использованием 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 был легок в настройке и настройке. TFS не было. 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? Ответ в моем магазине, к сожалению, очень маленький IMO.

Answer 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. Но IMO система управления сборкой должна быть довольно независимой от того, что строится и как она строится. Для нас дополнительный контроль в процессе управления релизами, который принес нам TFS, был недостаточным бонусом, чтобы оправдать значительно возросшие административные усилия полностью интегрированного решения TFS. Этого также было недостаточно для обоснования дополнительных затрат на лицензию TFS, которые могут быть значительными.

Answer 5

Сравнение 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 6

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

Answer 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 вам необходимо обладать некоторой гибкостью и возможностью выбора, когда вы решите использовать разные тестовые среды, библиотеки утверждений и т. Д.

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

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

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