CI: Hudson с .Net против CruiseControl.Net

Я не могу придумать ни одной вещи, которую Хадсон не смог сделать для нашей разработки на C #, даже с тестами на основе MSTest, теперь вы можете запускать и отображать тенденции на них с помощью новый плагин (работает только при тестировании ОДНОЙ сборки) или мой метод, который работает с несколькими сборками.

Я полагаю, единственное, что было бы неплохо, - это сгенерировать данные о покрытии кода и сообщить об этом, не уверен, что CC.net делает это.

Кроме того, похоже, что у Хадсона гораздо более сильная поддержка сообщества. Я никогда не слышал, чтобы кто-то предпочел CC.net Hudson, если бы у них был выбор.

Мы используем это, чтобы

• Развертывание служб Windows
• Развертывание веб-сервисов
• Запускайте MSTests и отображайте столько же информации, сколько и любые тесты junit
• Следите за низкими, средними, высокими задачами
• предупреждения и ошибки трендграфа

Возможно, эти вещи не являются чем-то новым для Хадсона, но я почувствовал необходимость еще раз подчеркнуть, что Хадсон может справиться с этим с помощью проекта .net, без проблем.

Вот некоторые из встроенных файлов .net, которые поддерживает Hudson

• MSBuild
• NAnt
• MSTest (два метода, ссылки выше)
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• предупреждения компилятора
• задачи кода

Кроме того, не дай бог, вы используете безопасный визуальный источник, это тоже поддерживает. Я бы порекомендовал вам взглянуть на Redsolo статья о создании проектов .net с использованием Hudson

Гудзон намного проще для новичков. Мы используем его для автоматической сборки и упаковки dll и exes C ++ Builder. Подумай об этом! Это не Java и не C #.

Я почти ничего не знаю о Гудзоне. Я скажу, что, поскольку CC.NET основан на .NET, он, как правило, имеет множество встроенных и созданных сообществом задач и отчетов, касающихся экосистемы .NET:

MSBuild Visual Studio NCover NUnit FxCop и т. Д. И т. Д. И т. Д.

Итак, если вы используете эти инструменты, вам следует внимательно проверить, насколько хорошо они поддерживаются Hudson "из коробки". Кроме того, если вам в конечном итоге придется писать собственные плагины (я сделал несколько для CCNET), обычно полезно иметь возможность использовать язык разработки и IDE, которые вы используете для «нормальной» разработки.

Я проверил поддержку Hudson для фреймворков тестирования xunit, краткое изложение приведено ниже:

• MBUnit / Gallio: есть плагин, но разработка, похоже, не слишком активна, и сообщество, которое используй это. Например, добавлена ​​только одна проблема. Об этом сообщалось в отчете в апреле и пока не тронут (август). (Команда Gallio поддерживает плагин для CC.Net, их время отклика выглядит намного лучше)
• MSTest: Та же проблема. Имеет только две проблемы в системе отслеживания проблем, а средняя задержка ответа составляет 6 месяцев. (Похоже, что CC.Net имеет встроенную поддержку mstest, но требует некоторой настройки)
• nUnit: поддержка nunit в hudson кажется неплохой. Команда разработчиков гораздо более отзывчива, и у нее также есть сообщения об ошибках (в настоящее время 8).

Так что я думаю, что собираюсь попробовать CC.Net.

Я не могу понять, почему разработчик .Net использовал бы инструмент Java CI. CruiseControl - это инструмент, ориентированный на Java. Вот почему был создан CruiseControl.NET. .NET-ориентированная непрерывная интеграция.

Если вы хотите настроить тесно интегрированную систему, вы будете писать свои собственные плагины для системы, чтобы она делала именно то, что вы хотите.

например Соберите воедино всю интересующую вас информацию о версиях, а затем запишите файлы AssemblyInfo.cs с версиями в них.