Блог

Рассмотрим проект Maven с несколькими взаимозависимыми модулями: скажем, три модуля jar A, B и C, которые являются зависимостями для модуля war Z. У меня есть отдельная сборка Hudson для каждого из этих модулей, так что заново создаются только измененные модули.

Моя проблема в том, что если я зафиксирую набор изменений, который изменяет как модуль A, так и модуль Z, Z может быть построен до A и завершиться неудачей, прежде чем A завершит и запустит перестройку Z, которая теперь проходит. Разрешение регулярных сбоев сборок по причинам, связанным с порядком сборки, а не с «реальными» сбоями, снижает чувствительность к реальным сбоям; в конечном итоге мы игнорируем сборки, которые были законно сломаны, потому что мы привыкли предполагать, что в конечном итоге они будут откатываться.

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

Это означает, что мои модули jar постоянно создаются, лишь изредка оставляя пробел для сборки моих модулей war. Таким образом, war создается не очень часто, что означает, что требуется много времени, чтобы выяснить, когда мы его нарушили, а также требуется больше времени, чтобы определить, какое изменение его нарушило.

Кроме того, постоянное выполнение сборок означает, что если я зафиксирую изменение, которое касается jar A и B, файл войны Z может быть собран один раз для jar A (который строится быстро), а затем снова для jar B (что занимает больше времени).). Это затрудняет понимание результатов данного коммита.

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

Есть ли какие-либо лучшие способы справиться с этим?

Спасибо

Это всегда сложная проблема (и я переписывал этот ответ не один раз!)

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

Я думаю, вам нужно посмотреть, почему выполняются ваши задания и как часто. Если в вашей WAR есть какой-либо код, требующий модульного тестирования, не могли бы вы перенести его в собственный модуль? Таким образом, вы можете запускать только интеграционные тесты каждый час / 30 минут, используя war, и не беспокоиться о том, где и когда находятся отдельные модули.

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

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

Подход, который мы сейчас рассматриваем, заключается в объединении некоторых модулей Maven в отдельные задания Hudson, а не в сопоставлении модулей с заданиями один к одному.

В частности, если зависимости модуля war довольно малы и их быстро создавать самостоятельно, их создание в одном задании с war гарантирует, что весь код из одного коммита будет собран вместе, по крайней мере, для данного файла war.

Это приводит к дублированию — у нас есть несколько файлов war, использующих одни и те же банки, поэтому банки по существу перестраиваются для каждой войны, а не только один раз. Но на практике jar-файлы создаются быстро, и это делает файлы war концептуально более чистыми.

Это было бы менее привлекательно, если бы для сборки и тестирования jars требовалось некоторое время, поскольку комбинированное задание jars war было бы довольно длинным, что дало бы нам длинные циклы обратной связи для проблем внутри jars. Важно правильно сбалансировать.

Итак, мой вывод: не думайте, что одно задание Hudson / Jenkins на модуль — лучший способ, и не бойтесь перестраивать один и тот же код в нескольких заданиях.