Блог

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

Есть ли у кого-нибудь опыт в том, как оптимизировать сборки непрерывной интеграции для больших проектов. Хороша ли функциональность инкрементной сборки Maven или Hudson? Я бы предпочел не ждать всегда 2 часа, внеся лишь небольшое изменение в один модуль.

С другой стороны, чтобы быть уверенным, вам всегда придется перестраивать и повторно тестировать по крайней мере все прямые и косвенные зависимости измененного модуля. Это также то, что мы в настоящее время делаем с Hudson, автоматически запуская все зависимые задания.

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

Спасибо за любые мысли.

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

С помощью плагина инкрементной сборки можно выполнять сборку без очистки. Каждый измененный модуль будет перестроен, плюс все зависимые компоненты будут очищены и перестроены. Однако в моем случае на компиляцию уходит примерно 10% времени сборки, 90% приходится на тестирование. И когда я устанавливаю / развертываю, все тесты выполняются снова, поэтому временная выгода от плагина инкрементной сборки очень мала.

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

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

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