Почему я плагин для Maven писал

image

Все началась, когда я поменял работу и сходу попал на большой проект. Большой для меня это несколько вендоров, десяток систем, 5-ти ступенчатый релизный цикл, 1000+ инженеров в разных локациях. Исходники «жили» в нескольких svn репозиториях с большим количеством maven модулей, каждый из которых мог использоваться в одной или нескольких системах. Каждый модуль был подключен в основную систему через бинарную зависимость. В конце релизного цикла необходимо было выпустить новые версии модулей и собранных на их основе систем. Под катом я опишу проблему эффективности этого процесса, с которой я попытался побороться — и что из этого вышло.

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

Пример, как все работало на нашем проекте:

  • Есть модули A, B, C и 2 системы X, Y;
  • X собирается из A (версия 1.0.0), B (1.1.0);
  • Y Собирается из B (1.8.0), C(1.0.0);
  • Модуль B может зависеть, например, от А;
  • Зависимости прописаны в корневых pom.xml каждой из систем, как бинарные (смотрите ниже);
  • В конце цикла разработки необходимо: выпустить релиз изменившихся модулей и новые версии X и Y (увеличить версию).


	<dependencies>
	      <dependency>
	        <groupId>B</groupId>
	        <artifactId>B</artifactId>
	        <version>1.1.0</version>
	      </dependency>


Проблема

  • Есть люди, ответственные за релиз каждой системы. Соответственно, они были вынуждены в конце каждого релизного цикла (1 месяц) искать все изменения по всем модулям, новые версии которых должны были войти в релиз и после этого выпускать новые релизы изменившихся модулей и в правильной последовательности (см п.4 примера), обновить секцию корневого pom.xml своей системы ссылками на свеженькие версии выпущенных модулей;
    Модулей действительно много, некоторые менялись, некоторые – нет;
    Инженеров тоже много и узнать, нужны ли изменения отдельно взятого модуля в системе X и Y обычно можно только с помощью человека, который делал эти изменения, и его начальника.
  • +14
  • 6,5k
  • 9
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 9
  • +7
    1000К+ инженеров

    1 миллион инженеров?
    *поднимает челюсть*
    • 0
      Спасибо, исправил.
    • +1
      Такое подозрение, что здесь не автоматизация скрипта нужна (хотя и его тоже поправить было правильно), а просто нормальный бизнес-процесс, включающий в себя какой-нибудь issue-tracker (на примере JIRA могу сказать, что легко «узнать, не собирается ли автор ещё чего-нибудь закоммитить» (статус ready for build весьма красноречив) внутри какой-либо компоненты, узнать нет ли ещё незавершённых тикетов для определённой версии компоненты.
      • 0
        Согласен, процессы — наша проблема, устаканить их среди нескольких вендоров не получилось. Почти над любой системой сейчас работает 2-3 компании. Насколько я понимаю, таким образом бизнес уменьшает зависимость от одного вендора.
        • 0
          Если действительно «несколько компаний», то не надо «разбираться какой компонент релизить» — каждая компания должна вести свои компоненты и релизить их самостоятельно. И они сами будут видеть от кого они зависят. А те, кто зависят от них — будут смотреть на них, а не на суб-зависимости.
          • +1
            Хорошо бы, если бы было так, как вы написали. На практике команды формируются под проект из свободных на данный момент разработчиков разных компаний. Кажданая команда может менять некоторое количество модулей. Вот почему закрепить модуль даже за компанией не всегда не получается. Более того, бизнесу нравится такое положение вещей, если один вендор отвалится(не будет продлевать контракт), то они найдут инженеров знакомых с этим модулем в другой компании.
      • 0
        Поидее если вы релизите какоют версию собоирающуюся из дерева зависмимостей, то вам интересно собрать тольло релизы выпущенные на данный момент не форсируя дополнительные релизы (звоня этим самым ленивиым инзехенерам)…
        Если какя то команда закончила свою работу над спец модулем где-то глубоко в зависмостях продукта… То сама команда и должна бы промоутать эту новую но тестированню версию… релизнутую версию.
        А топ проект уже сам решает включить ему новшество в свой релиз или нет. Если да то при релизе провести тесты с этой новой либой…
        Проблема ИМХО в планировании релизов…
        • 0
          Иногда, если команда успела все сделать, то сама промоутит, тесты прогоняет — но бывает всякое. Все правильно, проблемы в процессе и написанный плагин их не решает, а лишь помогает топ проекту видеть список «новшевств» (обновленных моделей) и нчего не упустить.
        • +1
          У нас немного другая структура проекта habrahabr.ru/post/154779/ но столкнулись с теми же проблемами. Решилось просто — написанием полноценного maven-плагина, который начинает выпускать текущий модуль, спускается по иерархии зависимостей до самого низа и запускает выпуск версий\подверсий модулей, предварительно проверяет, есть ли релиз для текущего снэпшота, если есть, то берет его. В итоге время выпуска сократилось раз в 5 и рутинная работа по сверке версий, коммитам в SVN пропала.
          Работает этот подход, правда, только когда сборка корректна. А то бывает такое, что некоторые разработчики начинают использовать транковые версии модулей в ветках сопровождения, но с этим мы боремся и сделали защиту выпусков в плагине.

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