Непрерывная сборка сервера непрерывной сборки (cc.net, hudson, bamboo и т. Д.)?

В настоящее время мы используем один раз сервер cc.net для нашего процесса сборки, который собирает как .net (используя msbuild & nant), так и java (используя maven и ant).

CC.net контролирует управление исходным кодом и запускает удаленную сборку, запущенную на отдельном сервере. Затем CC.net сопоставляет результаты.

Когда мы запускаем удаленную сборку, это обычно:

• работает nunit или junit или аналогичные с использованием поддельных данных
• При желании запускается сценарий БД для создания нового экземпляра базы данных или восстановления базы данных с известной позиции.
• запускает селен или похожий на тестовый интерфейс
• запускает emma или ncover для покрытия кода
• строит систему для различных сред развертывания (тестирование, приемка, производство)

У нас может быть запущено несколько сборок одновременно, некоторые .net и некоторые java (из разных проектных команд).

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

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

Хадсон (Обновление: в современном мире я бы использовал Jenkins, вилку Гудзона.)

Я использовал Hudson в корпоративных средах Java и .NET для проектов с высокой наглядностью (возможно, вы посещали некоторые сайты). Хадсон с самого начала добротен, но самое приятное в том, что существует множество плагинов, позволяющих делать практически все, что вы захотите. Hudson легко настраивается, имеет большое сообщество и его действительно легко настроить в кластерной среде, если вам нужно одновременно выполнять несколько сборок. Это мой любимый CI-сервер из всех, которые я использовал (CC.NET, Hudson и TFS).

Кроме того, вы можете использовать плагин ChuckNorris, чтобы он показал вам большие пальцы вверх или вниз.

Мы столкнулись с этим вопросом некоторое время назад и решили пойти с TeamCity . Мы смотрели только на Hudson, CC и TeamCity. Выбор был прост - TeamCity стал нашим сервером сборки. Обратите внимание, что я не профессионал в этом, и это был мой первый опыт работы с серверами сборки в то время.

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

Круиз-контроль - такой же, как у Гудзона, но немного по-другому. Абсолютно ничего не может быть понято там без руководства и тонны помощи от Google. Я просто продолжал смотреть на TC.

TeamCity - TeamCity чувствовал себя раем после первых двух. Это самый полезный из этих трех. Установите, перейдите в админ-панель, настройте проект (покажите, где находится SVN, укажите для создания файлов, укажите покрытие / модульные тесты и т. Д.) И начните наслаждаться. И хотя я не могу сказать, что я ничего не гуглил, все же 95% процесса установки были очень простыми и понятными. Я очень рекомендую этот инструмент. Иди и посмотри на это. Это сэкономит вам много нервов и времени :)

Также должен отметить, что ТС не является бесплатной. Хотя у них есть бесплатная версия, которую можно использовать в коммерческих проектах с некоторыми ограничениями (max build config 20) - взгляните на их страницу с ценами.

PS Звучит так, будто я работаю на ТС, но на самом деле нет :)

Мы используем CC.NET 1.4.

Мы пытаемся обновить до 1.6 ... какой кошмар.

Это мощно ... но ТОЛЬКО если вы правильно его используете и понимаете, как все сходится. Который очень много просить от всей команды. У нас есть «мастера сборки», которые имеют доступ к серверу и могут изменять настройки. Несмотря на это, в отношении ccnet существует много Googling, и весь бизнес превратился в огромный беспорядок.

Я лично хочу перейти в TeamCity.

Я рекомендую держаться подальше от ccnet.

хороший вопрос. В настоящее время мы также пытаемся выяснить, какой инструмент подходит нам лучше всего. Так что я только смогу рассказать вам немного опыта. Но нам было бы очень интересно, какую систему CI вы выбрали сейчас и по каким причинам. Поэтому, пожалуйста, держите нас в курсе.

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

Теперь к нашему опыту до сих пор:

Для проектов Java мы используем Bamboo, который прекрасно работает с использованием JUnit и Emma. И не так много усилий, чтобы создать новый проект.

Для проектов .NET мы все еще ищем лучшее решение

• Круиз-контроль: мы не смогли запустить его из-за проблем с подключением к нашему репозиторию

• TFS:

  а) Есть несколько шагов настройки, необходимых для выполнения первой сборки.

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

  c) Что касается ссылочных библиотек, есть также некоторые вещи, которыми нужно управлять, если вы хотите поделиться библиотеками для многих проектов и не хотите обрабатывать их в каждом отдельном проекте.

  г) Выполнить тест NUnit не так просто, как мы думали. Это просто, если вы используете выполнение теста, предоставляемое Visual Studio, но это не NUnit

  e) Мы еще не пытались запустить NCover (обо всем по порядку :-))

• Хадсон: Следующий инструмент, который мы попробуем. Кажется, есть действительно хороший и простой плагин для .NET, я дам вам знать, как это работает

• Бамбук: Первое предсказание, которое мы получили: «Слишком специфично для Java». Но, возможно, мы все же попробуем плагин .NET, я дам вам знать

Надеюсь, мы сможем продолжить это обсуждение и обменяться опытом.

Энди