Комментарии 4
Тема мониторинга не раскрыта совсем.
Мониторинг как таковой заслуживает отдельной статьи, в данной статье рассматриванием мониторинг с точки зрения удобства подключения к проекту. Если в двух словах - то для измерений пользуемся micrometer который входит в нашу экосистему разработки и подключается автоматом в проекты, дополнительно используем micrometer-jvm-extras который предоставляет чуть больше информации по памяти jvm приложения. Метрики собирает prometheus, его же используем для рассылки алертов, а дашборды делаем в grafana.
Сейчас набегут люди и будут мне объяснять, что я не прав (и возможно я действительно не прав), но... Отвергать мавен из-за его не "лаконичности" - такой себе резон. Сколько не работал со сборками на мавене или гредле никогда не было проблем с пониманием зависимостей, тиражированием. Проблема с гредлом появляются тогда, когда начинают писать свои плагины - а рано или поздно так происходит - так как появляется рандомный принципал инженер, который эту практику притаскивает и увольняется. И еще: я может просто не понимаю про какие "комбинации настроек" вы говорите, что их версии мешают вам собирать проекты - лично я считаю, что система сборки не должна вообще ничего знать о версионировании и каких-то настройках - это не её забота. Если нужны определенные версии 3rd party зависимостей - делаешь parent pom, суёшь в него properties и переиспользуешь его в других репозиториях, при этом совсем не обязательно иметь один моно-репозиторий.
Лаконичность достаточно субъективный параметр, мне например не нравится писать много xml и я теряюсь в нем, но кому-то приемлемо и даже проще читается. Все что вы перечислили действительно решается и maven и gradle без использования плагинов. Вопрос только в опыте, предпочтениях и вкусе - в нашем случае сложилось так что большинству зашел gradle, плагины хорошо дополнили и упростили сборку для всех.
Разработка, сборка, деплой и мониторинг сервисов: от общего к частному и обратно