Как я могу отключить определенные модули в Hudson, не изменяя совершенный pom? - PullRequest
1 голос
/ 01 февраля 2011

Я использую Hudson для огромного Java-проекта.В проекте участвуют 2 команды, поэтому очень важно разбить сборку, и отчеты о неудачных юнит-тестах или обрывах сборки должны быть запущены как можно быстрее!Чтобы добиться этого, мы используем одну ежедневную непрерывную сборку, которая запускается очень часто и просто выполняет задачи «чистого теста» только для измененных модулей и их зависимостей.

Это хорошо, но недостаточно, сборка все еще слишком медленная, и я хотел бы деактивировать некоторые модули, которые выполняют интеграционное тестирование в конце процесса сборки и которые не имеют отношения к «почасовой» работе.специально для команды, работающей над частью пользовательского интерфейса.

Есть ли способ настроить Hudson на отключение некоторых модулей без взлома файлов pom?

Ответы [ 3 ]

2 голосов
/ 03 февраля 2011

"Это нормально, но не достаточно, сборка все еще слишком медленная, и я хотел бы отключить некоторые модули, которые запускают интеграционный тест в конце процесса сборки "

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

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

1 голос
/ 01 февраля 2011

Насколько я знаю, Hudson/Jenkins выполняет только ваши файлы сборки, я думаю, что в задачи CI не входит настройка проекта.

Так что для меня взлом файлов POM, кажется, единственный выбор.

0 голосов
/ 14 марта 2011

Еще один способ ускорить процесс - это создавать только те модули, которые изменились (так как те, которые еще не были, будут в вашем локальном или корпоративном репо с прошлого раза). опция: «Инкрементная сборка - только сборка измененных модулей», которая делает это. Исключение модулей, которые изменились только потому, что они имеют интеграционные тесты, кажется довольно опасным. Как и на самом деле, весь смысл CI в том, чтобы строить как можно быстрее после изменения.

Что вы можете сделать, что не должно включать слишком много изменений, хотя бы разделить ваши тесты на медленные и быстрые, используя такую ​​технику, как профили сборки. Например. менее 1 секунды быстро. Достаточно легко разделить их, как это, и это также подскажет разработчикам, которые являются медленными тестами. Затем вы можете создать цепочку сборок, чтобы быстрые сборки запускались первыми, давая разработчикам обратную связь в кратчайшие сроки. Если эта сборка завершится успешно, она может запустить более медленные тесты, оставляя обратную связь в минимально разумное время. Эти тесты все еще увеличивают ценность и должны выполняться как можно чаще.

Если вы решили объединить свои задания, взгляните на плагин сборки конвейера , который был настроен для определенного сценария.

...