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

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

Итак, наша установка:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Посмотрите на www.tfsbuild.com "рецепты" различных конфигураций Team Build.

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

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