Чому я плагін для 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 прикладу), оновити
    <dependencies>
    секцію кореневого pom.xml своєї системи посиланнями на свіженькі версії випущених модулів;
  • Модулів дійсно багато, деякі змінювалися, деякі — ні;
  • Інженерів теж багато і дізнатися, чи потрібні зміни окремо взятого модуля в системі X і Y зазвичай можна лише за допомогою людини, який робив ці зміни, та його начальника.


Як вирішували
Процес повністю автоматизувати не вийде, так як не вистачає інформації, яку версію залежно потрібно поставити в релізі системи. Ну, робимо що можемо — на Python був написаний скрипт, який виводив всі залежності, в яких були зроблені хоч які-небудь зміни за минулий релізний період. Далі цей список розподілявся серед відповідальних інженерів, які «не сильно зайняті в даний момент», кожен з яких для своєї частини:

  1. Знаходив де «живе» модуль в svn, дивився останні зміни за період;
  2. Зв'язувався з тим, хто туди комитил щоб дізнатися потрібно/можна релізувати або «почекай ще трохи я баг закрию»;
  3. За допомогою release плагіна до maven створював нову версію, гілку в svn, оновлював версію pom.xml.


Як і всі ледачі програмісти я став намагатися оптимізувати це дійство, яке відволікало купу народу на пів дня. Коли я зрозумів, що людське участь тут дійсно необхідно і все що можна було поліпшити це процеси комунікації, я перестав думати над поліпшенням неавтоматизованої частини і переключився на шматок, автоматизований скриптом. Мені не подобалося, що:

  • Використовується кастомный скрипт, який, як я пізніше дізнався у людей, його використовують, не читав значення
    <scm>
    тега, а тримав посилання кожного модуля на його SVN_URL в текстовому файлі;
  • Так само скрипт виводив плоский список, а не дерево залежностей. Дерево допоможе визначити, в якій послідовності потрібно релізувати артефакти;
  • Не виводив авторів останніх комитов, що могло допомогти у розподілі, хто ж буде релізувати модуль.


Перша думка була тоді — «Навіщо писати кастомное, якщо все є в maven?»

Maven
Постановка завдання: написати плагін під Maven, який покаже дерево залежностей всіх модулів з інформацією про його поточної версії і логом останнього комита за певний період.

Для початку я пройшовся по існуючій базі плагінів і подивився, що такого велосипеда і саме з перламутровими гудзиками ще немає. Але з корисного, я дізнався якими плагінами можу скористатися всередині свого. Про те, як розробляти плагін, вже писали на хабре, повторюватися не буду, але з труднощів пам'ятаю, що досить сильно заважало вимога на нашому проекті використовувати Maven версії 2.x і не вище. Доводилося шукати плагіни, які працюють під 2.x.

Як він працює:

  1. Використовує Dependency tree builder maven dependency plugin;
  2. Для кожного модуля з дерева будує опис Maven проекту в пам'яті. Опис проекту бере або з локального pom.xml або з Maven сховища;
  3. Читає
    <scm><connection>
    інформацію для кожного проекту. Якщо в поточному
    pom.xml
    ця інформація відсутня, то дивиться батьківський проект.
  4. Використовуючи SCM Maven provider та інформацію, отриману на попередньому кроці, отримує список змін за вказаний період;
  5. Виводить все легкочитаємом файл.


Висновок
Вийшло досить просто. Посилання на джерело https://github.com/temas-hub/changed-maven-plugin і там же — як ним користуватися. Буду радий, питань і зауважень. Сподіваюся, хтось знайде цю статтю корисною.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.