CruiseControl [.Net] против TeamCity для непрерывной интеграции?

Я хотел бы спросить, какую среду автоматизированной сборки вы считаете лучше, исходя из практического опыта. Я планирую заняться разработкой .Net и немного Java, поэтому я хотел бы иметь инструмент, поддерживающий обе эти платформы.

Я читал и узнал о CruiseControl.NET , используемом при разработке stackoverflow, и TeamCity с его поддержкой для агентов сборки на разных платформах ОС и на разных языках программирования. Итак, если у вас есть практический опыт работы с обоими из них, какой из них вы предпочитаете и почему?

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

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

Я работал с инструментами непрерывной интеграции с тех пор, как породил круиз-контроль (версия java). В какой-то момент я перепробовал почти все из них. Я никогда не был счастливее с TeamCity, чем я. Его очень просто настроить, но он по-прежнему обеспечивает большую мощность. Страница статистики сборки, которая показывает время сборки, количество модульных тестов, скорость прохождения и т. Д., Очень хороша. Домашняя страница проекта TeamCity также очень ценна. Для простых .NET-проектов вы можете просто сообщить TeamCity, где находится решение и какие сборки имеют тесты, и это все, что ему нужно (кроме местоположения системы управления версиями). Мы также использовали несколько сложных сценариев MSBuild и выполнили построение цепочки. Я также прошел через два обновления TeamCity, и они были безболезненными.

CruiseControl.NET тоже хорошо работает. Его сложнее настроить, но он имеет более долгую историю, поэтому решения в Интернете легко найти. Поскольку CruiseControl.NET имеет открытый исходный код, у вас также есть возможность добавлять или изменять все, что вам нравится. Я использовал CruiseControl.NET с момента его выпуска и написал часть раннего кода для cc.tray (к счастью, переписанный кем-то, кто знал лучше).

Cruise от ThoughtWorks тоже выглядит неплохо, но я не вижу веских причин для перехода. Если бы я начинал новый проект, я мог бы попробовать, но TeamCity проделала огромную работу, упростив простые вещи, а сложные - безболезненными.

Изменить: мы только что обновились до TeamCity 5.0 несколько недель назад, и это было еще одно безболезненное обновление. Это позволило нам воспользоваться улучшенными возможностями покрытия кода и поддержкой GIT. Мы также теперь используем личную сборку и предварительно протестированные функции фиксации, которые были в наличии. Я просто подумал, что мне нужно обновить ответ, чтобы указать, что TeamCity продолжает улучшаться и по-прежнему прост в использовании.

Я был / я большой поклонник CC.NET. На данный момент у нас в CruiseControl 5 проектов, и они отлично работают. Написание файлов конфигурации вручную может быть болезненным, но это нормально.

Но ...

После скринкаста Kona: Continuous Integration and Better Unit Testing (первая 1/3 о TeamCity) я тоже проверю TeamCity. Мне нравится интегрированная панель модульного тестирования и интерфейс конфигурации.

Я думаю, что каждый должен посмотреть это видео, прежде чем выбирать CC.NET или TeamCity.

ps: Я надеюсь, что в сети есть ценное видео о CC.NET.

Мой любимый CI-сервер на сегодняшний день - Hudson. Легко настроить и поддерживать, множество хороших графиков для отображения тенденций для разработчиков и не разработчиков, и бесплатно.

В настоящее время я использую TeamCity в проекте и в целом доволен этим, но многие из создаваемых им графиков не особенно полезны, и их сложнее настроить, чем Hudson.

Тем не менее, TeamCity является мощным, бесплатным для многих применений и имеет одну потрясающую функцию: удаленный запуск. Вы можете «предварительно зафиксировать» свою проверку прямо из IDEA или Eclipse, запустить одну или несколько конфигураций сборки на сервере TeamCity и зафиксировать изменения только в случае успешной сборки (например, компиляция и все тесты пройдены).

Учитывая, что вы можете запустить и TeamCity, и Hudson за несколько часов, возможно, стоит взять их и запустить вместе с любыми другими (например, CruiseControl), о которых вы можете подумать. Если вы не можете быстро подключить CI-сервер для параллельного сравнения, то, по крайней мере, у вас есть точка данных для упрощения установки и / или настройки.

Я успешно использовал их обоих в разных проектах. С точки зрения настройки и администрирования с Team City гораздо проще иметь дело. Вам не нужно возиться с файлами .config, как с CC, и настройка выполняется очень просто. Поскольку у вас не так много проектов, я бы рекомендовал Team City вместо CC, пока вы не дойдете до того, что Team City стоит $ $$.

Я использовал и CC.net, и TeamCity. Мне поручено настроить и установить TeamCity для моей организации (5 разработчиков). Наша организация использует некоторые необычные методы и инструменты (по крайней мере, для организаций нашего размера), такие как Perforce для управления версиями и несколько агентов сборки, работающих в гетерогенных операционных системах, что вызывало некоторые проблемы при начальной настройке. Тем не менее, поддержка по электронной почте была абсолютно первоклассной в настройке всего. Я получил ответы на свои глупые вопросы буквально за несколько минут.

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

Я чувствую, что мы используем практически все дополнительные функции продукта и пока не обнаружили никаких ошибок. Интеграция с Ndepend, вложенные сценарии NAnt, маркировка версий Perforce, вы называете это, мы делаем это.

Я настоятельно рекомендую TeamCity всем, кто ищет сервер непрерывной интеграции или любой другой сервер сборки.

Не желая бросать вам альтернативные инструменты :-)

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

https://hudson.dev.java.net/

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

Я использую CruiseControl.Net, но я бы не рекомендовал его для создания большого количества проектов ... У меня есть (возможно, немного странное) расположение, где у меня есть много статических библиотек C ++, которые я составляю в приложения. Каждая библиотека зависит от других библиотек, и приложения используют набор библиотек и сборки. В каждой библиотеке есть набор тестов. У каждого приложения есть набор тестов. Я строю для 5 компиляторов и вариаций (windows) платформ.

Первое, что я обнаружил, это то, что триггеры проекта CC.Net на самом деле не совсем то, что вам нужно, а мульти-триггер плохо работает с триггерами проекта. Способ работы триггеров проекта (они используют удаленное взаимодействие для подключения к серверу, на котором хранится проект (даже если это проект, которым управляет один и тот же экземпляр CC.Net), а затем извлекают все проекты с этого сервера и последовательно просматривают список поиск интересующего вас проекта ...) означает, что они плохо масштабируются. Как только вы превысите определенное количество проектов, вы обнаружите, что CC.Net занимает большую часть ЦП для вашей машины сборки.

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

Более подробную информацию о моих проблемах и некоторых патчах для CC.Net смотрите здесь. http://www.lenholgate.com/archives/cat_ccnet.html

Я недавно установил cc .net. Это отличное приложение, но требует немного терпения. Вы будете много редактировать файлы конфигурации в блокноте :)

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

Я не использовал TeamCity, но слышал довольно много рекомендаций, и это выглядит красиво.

У меня был опыт настройки и запуска CruiseControl (версия Java) в Linux во время моей предыдущей компании. Как предполагает большинство людей, это не самая тривиальная вещь в настройке. Вам нужно понять его структуру, чтобы придумать работоспособную / управляемую конфигурацию. Однако, как только вы миновали эту горку, я чувствую, что CruiseControl достаточно гибок, чтобы вы могли делать разные вещи в соответствии с разными сценариями.

Помимо документации CruiseControl, на ее вики-странице также есть полезная информация.

У меня нет прямого опыта работы с TeamCity. Хотя его функция предтестовой фиксации выглядит достаточно интересно.

Другой инструмент CC, на который вы могли бы взглянуть, - это Bamboo от Atlassian. Настроить намного проще, а интерфейс приятнее. Хотя он не такой гибкий, как у CruiseControl.

Третий вариант, который вы, возможно, захотите рассмотреть: круиз Thoughtworks. Он построен на CruiseControl, но предлагает гораздо больше возможностей, более простую настройку и т. Д. Не бесплатно (или с открытым исходным кодом).

http://studios.thoughtworks.com/cruise-continuous-integration

Я использую Teamcity последние полтора года и имею большой опыт. Я интегрировал ряд проектов .Net и Java и использовал такие инструменты, как MSBuild, Maven и т. Д. Я нашел Teamcity довольно простым в настройке и работе с ним. Мне также удалось запустить CI для некоторых проектов sql, что было немного кошмаром, который мог быть хуже с другими инструментами CI.
Недавно обновился до Teamcity 8.0.6, что было безболезненно. Также Teamcity предоставляет REST API, который очень полезен для некоторых сценариев. Если вы используете PowerShell для автоматизации сборок, на GitHub доступен ряд сценариев интеграции Psake / Teamcity.