Тезис: Как мы автоматизировали подготовку релизов в банке (Java 17, Spring), написали свой плагин для проверки release notes и обошлись без выделенного DevOps-инженера, используя чистый Java-стек в закрытом контуре.
Контекст: Боль энтерпрайза
Проект в банке. Закрытый контур (on-premise), жесткие требования ИБ. Стандартный maven-release-plugin не подходил из-за специфики монолита. Ручная подготовка каждого релиза занимала около часа, а любая ошибка в конфигурации стоила команде простоя.
-
Ручная подготовка: 60 минут → 5 минут.
-
Восстановление после ошибки: 24 часа → 15 минут (перезапуск job).
-
Поддержка решения: ≈ 2 часа в месяц.
-
Срок реализации: 2–3 недели.
Контекст и ограничения
-
Среда: Закрытый контур (on-premise), облачные сервисы недоступны.
-
Стек: Java-монолит (Maven, Spring, Oracle).
-
Команда: Выделенного DevOps-инженера нет, инфраструктура на плечах разработчиков.
-
Проблема: Перед релизом ручная архивация, поиск коммитов и сборка release notes. Любая ошибка могла затянуть релиз до суток.
-
Масштаб: Команда из 3 человек, релиз раз в 2 недели.
Архитектурные решения
Мы разделили ответственность: GitLab CI отвечает за оркестрацию, а кастомный Maven-плагин берет на себя сборку артефактов и валидацию.
Ключевые решения:
-
Логика в Maven: Вся логика сборки живет внутри плагина. Это позволяет отлаживать её локально.
-
Чистота репозитория: Мы не коммитим сгенерированные артефакты в Git.
-
Изоляция: Весь цикл разработки транслировался на изолированный GitLab Runner. Это позволило ломать билд в песочнице, не рискуя стабильностью команды.
1. Реализация плагина (JGit + Jira)
Для сбора release notes мы написали кастомный Maven-плагин.
-
Он использует JGit для получения дельты коммитов между релизными тегами.
-
Он обращается к Jira API, чтобы проверить статусы задач и включает в релиз только те, что находятся в статусе «Готово».
-
Каждая сборка получает уникальный хэш, а готовый архив (Git Bundle + сертификаты) сохраняется в артефакты.
Подробный разбор того, как именно устроен этот плагин, как он работает с файловой системой и как мы покрывали его тестами, я описал в отдельной статье CookBook maven plugin. CDI, отладка и тестирование. Там разобраны нюансы тестирования с помощью maven-plugin-testing-harness и работы с mvnDebug.
2. Тестирование плагина (The Harsh Way)
Тестирование логики плагина — самая сложная часть. Мы использовали maven-plugin-testing-harness. Особенность: При тестировании выяснилось, что хардкорные тесты ломают локальный репозиторий. Пришлось вынести тесты в отдельный модуль (verify-checks) и корректировать пути, чтобы тесты не конфликтовали с основным билдом. Весь процесс сборки и тестирования мы детально разобрали в вышеупомянутой статье на Хабре.
3. CI/CD: Сборка в закрытом контуре
Стандартный maven-release-plugin был отклонен. Мы реализовали свой конвейер в GitLab CI:
-
Сборка: Запуск нашего кастомного плагина.
-
Валидация: Проверка
release notesи статусов Jira. -
Артефакт: Готовый архив (Git Bundle + сертификаты) попадает в Registry.
-
Сборка: Запуск нашего кастомного плагина.
-
Валидация: Проверка
release notesи статусов Jira. -
Артефакт: Готовый архив (Git Bundle + сертификаты) попадает в Registry.
4. Отладка (Debugging) в изолированной среде
Отладка плагина на общем сервере банка — табу. Мы развернули изолированный GitLab Runner на персональном стенде. Весь цикл разработки новых шагов конвейера транслировался туда. Мы могли спокойно ставить брейкпоинты в IntelliJ IDEA (Remote Debug), подключаясь к процессу сборки на стенде.
Результаты
-
Время: Подготовка релиза сократилась с 60 минут до 5 минут.
-
Надежность: Исключены ошибки ручного копирования файлов.
-
Масштаб: Логика вынесена в Parent POM. Добавление нового проекта в пайплайн занимает 15 минут.
Заключение
Мы не просто автоматизировали сборку. Мы забрали у команды час рутины в неделю. Кастомный плагин на JGit позволил нам уйти от жестких рамок стандартных инструментов и адаптировать релизный цикл под реалии банковского энтерпрайза.
Источник: habr.com