Как организовать микросервисную архитектуру на Gradle?

Question

[xynbka]

Достался в наследство многомодульный Java проект.
структура следующая:
----------------------
libs
service1
--gradle.build.kts
--dockerfile
service2
--gradle.build.kts
--dockerfile
build.gradle.kts
settings.gradle.kts
versions.gradle.kts
docker-compose.yaml
----------------------
Весь проект хранился в одном репозитории bitbacket, запускался и тестировался с помощью общей таски gradle. Поступила задача разбить его на разные репозитории. Мы вынесли библиотеки в корпоративный Nexus. Но как правильно разбить его на микросервисы так, чтобы использовались единые версии библиотек, плагинов и тасков рутового build.gradle и versions файла. Или единственный рабочий вариант переносить логику сборки и версионирования библиотек в каждый отдельный микросервис? Или воспользоваться Git Submodules?

Answer 1

[Dmitry Roo]

gradle умеет билдить по одному модулю из коробки "чтобы можно было прогнать по pipeline CI не билдить его целиком":
gradle :service1:build

Comments

[Dmitry Roo]

Executing tasks in multi-project builds

[xynbka]

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

[Dmitry Roo]

xynbka, конечно можно. Я вам даже команду скинул как это делается.

[xynbka]

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