Управление большими многомодульными проектами в Subversion / Maven / Hudson

Question

У нас довольно большое Java-приложение, состоящее из множества артефактов maven. Каждая подсистема имеет свою собственную папку в дереве подрывной деятельности с вложенными папками ствола /, ветвей / и тегов / и содержит несколько артефактов. Иерархия Maven POM имеет несколько уровней. Даже управление зависимостями разделено на разные модули. Приложение развернуто как несколько WAR-файлов и других Zip / JAR-компонентов.

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

1. Subversion Layout : Все начинается с того, что я не могу просто извлечь всю кодовую базу одной командой. Он просто слишком большой и займет слишком много времени, когда я начну с верхнего уровня и извлечу все ветви из всех подпроектов. Я предполагаю, что сокращение количества артефактов в настоящее время не является действительно возможным вариантом, так как это вызовет слишком много фундаментальных изменений. Но может быть другая схема подрывной деятельности с агрегированными ветвями папок действительно поможет. Один из обходных путей, который я попробовал, - создать отдельную папку с множеством внешних воздействий, которые собирают правильные подпапки. Затем я могу, например, собрать все это одной командой maven из многомодульного артефакта верхнего уровня.

2. Выпуск : Выпуск выполняется по всей базе кода. Сначала я создаю огромный граф зависимостей, в котором я использую специальный инструмент, написанный специально для проекта, поскольку это невозможно сделать напрямую с Maven. Затем мне нужно постепенно высвобождать один слой артефактов в дереве зависимостей, начиная снизу с артефактов, которые не имеют каких-либо дополнительных зависимостей, строить их, в случае успеха, адаптировать родительские POM с новыми версиями и переходить на следующий уровень , Иногда мне хочется выполнить всю работу по созданию версий дважды: один раз в Subversion и еще раз во всех POM. Похоже, плагин релиза не может автоматически адаптировать управление зависимостями.

3. Хадсон : В Хадсоне у нас около 20 рабочих мест для всех родительских артефактов. И для каждого артефакта есть 3 активные ветви. Это составляет около 60 рабочих мест. Каждый раз, когда ветка меняется, она вызывает много щелчков мышью в браузере. По крайней мере, автоматический запуск сборки зависимых заданий работает. Но опять же, это вызывает проблемы, если модуль разделяется на задание компиляции и задание отчета. Обычно компиляция выполняется гораздо чаще, чем генерация отчетов, и последние не должны замедлять первое. Но затем, когда запускается задание отчета, оно также запускает все задания компиляции. Похоже, что Хадсон не может запускать зависимые задания, только если артефакт действительно развернут. Я также попытался сделать одну огромную многомодульную сборку для всего проекта, но функция инкрементной сборки не работает правильно. И без этого сборка занимает слишком много времени. Но создание зависимых артефактов является обязательным, так как вы никогда не можете быть уверены, какое изменение вызывает один артефакт.

4. Агрегированные отчеты : Я еще не выяснил, как генерировать агрегированные отчеты для модульных тестов, покрытия тестами, стиля проверки и других для каждого уровня родительских POM. Некоторые плагины даже не поддерживают агрегированную опцию. Для других я должен сделать сборку снова для каждого уровня в иерархии. Отчеты с сайта Maven в порядке, но они выглядят довольно статичными и имеют ограниченное использование при просмотре. Возможно, лучшим вариантом здесь было бы использовать что-то вроде Sonar Source или какой-либо другой инструмент анализа исходного кода. Кроме того, интеграция этих отчетов в Хадсон кажется мне не идеальной.

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

Answer 1

Я не знаю, является ли это упрощенным ответом, но у меня есть похожий проект (по кодам): 2 больших приложения, одно с примерно 10 модулями и одно с 15 модулями. У нас есть все в одном хранилище Subversion (например, svn / trunk / app1 и svn / trunk / app02). В корневой папке (svn / trunk) у нас есть очень простой pom, который определяет версию и оба приложения как подмодули.

С этой настройкой мы можем сделать большую часть того, что вы упомянули. Даже отделение от каждой команды разработчиков, так как каждая команда фиксирует свою папку / проект. Мы даже храним другие артефакты, такие как документация и дизайн (svn / trunk / Документация), поэтому мы можем отслеживать, какая документация у нас была для конкретной версии.

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

Примечание. Мы не генерируем комбинированные отчеты, так как мы больше заинтересованы в том, чтобы иметь отчет по каждому приложению, поскольку они совершенно разные.