Team Foundation Build или TeamCity?

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

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

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

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

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

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

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

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

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

во-первых, смотрите этот пост:

SVN против Team Foundation Server

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

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

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

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

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

сравнение 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.

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

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

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

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

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

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

перестань полагаться на Microsoft по-прежнему на гибкой предложений инструмент

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