Подтвердить что ты не робот

Круиз-контроль .Net против Team Foundation Build

Наша команда настраивает ночные и непрерывные интеграционные сборки. Мы владеем Team Foundation Server и можем использовать Team Foundation Build. Я больше знаком с CC.Net и так противно, но руководство видит все деньги, потраченные на TFS, и хочет использовать его.

Некоторые вещи, которые мне больше нравятся в CC.Net, - это гибкость уведомлений, а также простота реализации пользовательских сценариев.

Если у вас есть опыт работы с обоими продуктами, которые вы предпочитаете и почему?

4b9b3361

Ответ 1

Я использовал оба. Я думаю, это зависит от того, что ценит ваша организация.

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

Вот что мне нравится в Team Foundation Build:

  • Агенты сборки. Очень просто превратить любую коробку в машину сборки и запустить ее на ней. MSFT получил это право.
  • Отчетность. Все соответствующие результаты сборки (включая тест) хранятся в базе данных SQL и отправляются через службы отчетов SQL Server. Это очень мощный инструмент для построения диаграмм построения и результатов тестирования с течением времени. У CC Net нет встроенного устройства.
  • Вы можете выполнить аналогичные настройки через MSBUILD. Это в основном то же самое, что использование NAnt с CC Net

Вот что подталкивает меня к стене Team Foundation Build:

  • Для создания проектов С++/CLI (или выполнения модульных тестов...?) агент сборки должен иметь установленный VSTS Dev или Team Suite. Это, друзья, просто просто безумие.
  • Он должен быть подключен к материнству TFS

Если вы находитесь в большой организации с множеством боссов, у которых огромные бюджеты и отчеты о любви (и не поймите меня неправильно, это имеет огромное значение). Или вам нужно масштабировать до фермы с несколькими машинами, Я бы предпочел Team Foundation Build.

Если вы - более компактный магазин, придерживайтесь CC Net и создавайте собственные решения для отчетности. Это то, что мы сделали.

Пока мы не приобрели. И получил TFS: P

Ответ 2

Я предполагаю, что, когда вы владеете TFS, вы будете использовать его для контроля версий. В этом случае я склоняюсь к Team Foundation Build. Тем не менее, я в значительной степени согласен с Nick.

Я написал интеграцию CruiseControl.NET для TFS. Он отлично работает и дает вам те же возможности сборки, к которым вы привыкли. Для меня основным преимуществом CC.NET является то, что он полностью расширяемый и имеет интеграцию со всеми основными SCM и системами сборки под солнцем. Основная причина, по которой я писал интеграцию CC.NET в TFS, заключается в том, что в TFS2005 система сборки не имела встроенной поддержки CI. Однако версия TFS2008 значительно улучшена, и команда продолжает активно улучшать ее для будущих выпусков TFS.

Основной причиной перехода на TFS Build будет то, что он автоматически сообщает информацию о сборке обратно в TFS, что помогает завершить картину разработки программного обеспечения с точки зрения отчетности. Он также прекрасно сочетается со стороной отслеживания рабочих элементов TFS и внутри IDE (как в Visual Studio, так и в Eclipse).

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

Ответ 3

Реальное значение в Team Foundation Build заключается в том, что оно связывает изменения и рабочие элементы со строками.

Это позволяет использовать несколько полезных сценариев:

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

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

Взгляните на www.tfsbuild.com на "рецепты" в разных конфигурациях Team Build.

Ответ 4

SVN - это инструмент OK, намного превосходящий, это неправда, SVN и TFS похожа на Ford pickup против Mercedes 500, он выполняет свою работу, но это не очень и не удобно, слияние имеет многого желательно. Я предпочитаю инструмент слияния TFS, так как кажется, что ветвящийся разработчик работает с вами, так он умен. Наш внутренний SVN, похоже, сильно испортился, поэтому мы отбросили его и отправились в TFS и не оглянулись назад. Стеллажи наборов изменений являются прекрасными для быстрого развития магазина, в настоящее время имеют 270 инженеров на TFS без проблем или проблем, SVN просто не способен обрабатывать такую ​​нагрузку без проблем.

Я предпочитаю CC.NET просто из-за инструментов, которые мы разработали в доме, чтобы расширить функциональность в области отчетности и администрирования. Однако сборка TFS очень тесно интегрирована, и мы ожидаем перехода при обновлении до SQL 2008

Ответ 5

Мы используем CruiseControl.net с июня 2007 года, и это отлично подойдет для нас. Лучшая часть, она легко интегрируется в SVN, который является гораздо более совершенным поставщиком контроля источника.

Итак, наша настройка:

  • Cruise Control.Net
  • SVN
  • Trac - для отчетов об ошибках и управления проектами (идеально интегрируется с SVN)
  • nunit - для модульного тестирования

Мы провели крупную параллельную разработку, и опыт ветвления и слияния был впечатляющим. Если у вас есть выбор, я бы пошел с настройкой выше!