Setup a shared config for easy team development of spring-boot microservices

Help/Discuss
1

Hello,

In our team we have developed more than 20 micro-services with maven and used a lot of parent/child pom file so that anybody in the team has the ability to inherit a parent pom and have a project ready in a few seconds.

I’m trying to migrate one by one the existing projects to gradle but though I played already a bit with “apply from” I’m facing difficulties.

Most of our project are spring-boot project which requires us to apply io.spring.dependency-management plugin and even in buildscript and this plugin have to be downloaded through our nexus repository.

I already reduced the required information in the project gradle file by applying a common.gradle available in http and I already forsee different flavour of that common so that I can configure different types of project but my problem is about updating that buildscript part.

I achieved to reduce the gradle file again by placing buildscript part in ~/.gradle/init.gradle but this means all developpers of the team have to share that file somehow.

I’ve read something about writing an “team” plugin that would configure the project to work correctly inside the company but I would like to have as many advices as possible on how I could write once a shared configuration or many shared configuration files so that it’s easy for every new team member to setup his workstation without having to copy/paste a complete gradle configuration and be able to create project using spring-boot and spring-cloud-config with a very small build.gradle not having to repeat again and again the buildscript part in every new project.

Do you have any idea on how I have to structure this ?

2

We store our different projects/builds/services in a monorepo, then keep common gradle code in the same repository at a top level /gradle location.

I find a repository-per-service much too heavyweight and cumbersome, but you could still achieve the same thing using git subtree or submodule .

This works whether your common gradle code is uncompiled .gradle files, or compiled plugin code, you can still do a source level include of the latter using composite builds.

There is still some duplication I haven’t been able to get rid of (though I haven’t tried very hard), but it’s limited to declaring plugin version dependencies.