Zarządzanie propertiesami w springu

Cześć. Czy są jakieś dobre praktyki / sprawdzone patenty na zarządzanie propertiesami przy mikroserwisie?
Załóżmy, że mamy sobie projekt, który jest parentem dla reszty mikroserwisów (ma wszystkie configi, utilsy, wspólne biblioteki itd) no i mikroserwisy, które mają ustawionego parenta w pomie na niego.

Ja w projekcie póki co mam sobie osobne repo z propertiesami, gdzie mam wspólne propertiesty w application-properties i dodatkowo każdy mikroserwiś ma swój plik.

Niewygodne jest to, że przy podbiciu parentowego mikroserwisu trzeba też robić zmiany w tym osobnym repo z propertiesami.

Da się może jakoś zrobić tak, żeby te wspólne propertiesy siedziały nie w osobnym projekcie ale właśnie w tym parencie? Wtedy wydając nowy parent od razu wydam go za jednym zamachem z przygotowanymi propertiesami, a w osobnym projekcie po prostu będą siedziały te specifyczne dla mikroserwisu.

<nieznamsięaleodpowiem>

A nie od tego jest Spring Config ?

</nieznamsięaleodpowiem>

@ZrobieDobrze:
Ale spring config zaciąga z osobnego repo i to jest ok, a ja chcę defaultowo najpierw zaciągać propertiesy z projektu parenta, które siedzą w parencie.

Możesz przekazać "propertiesy" z parenta np za pomocą propertiesów mavenowych (tam gdzie w pom.xml ustawiasz np <spring.version>5.0.7</spring.version>).

Btw ludzie raczej mają odwrotny problem (Spring Boot zaciąga propertiesy z parenta, a chcą żeby zaciągał z submodułu), tutaj patrzyłeś?
https://stackoverflow.com/questions/45712306/spring-boot-using-properties-file-of-parent-module-instead-of-its-own

Jest pewna ilość nie-springowych bibliotek do konfiguracji, chyba każda ma taki dobór kolejności / priorytetów / przekrywania, że głowa mała.
W tej chwili nie przypominają mi się ich nazwy, moze pózniej

Trochę to dziwne, przecież mikroserwisy to właśnie rozdzielność kodu i konfiguracji. Podaj przykład jakiegoś propertiesa, który chciałbyś zmieniać globalnie.

Nie do końca rozumiem jakiego typu właściwości chcesz uwspólniać:

• coś na poziomie mvn, typu wersja biblioteki

• jawne wartości, typu dajmy na to jakieś wspólne url do np. bazy danych

• sekrety, typu hasło, token itp?

  Jeżeli chodzi o pierwszy przypadek, to nie wiem, przeszliśmy na Gradle. Jedne problemy zniknęły, inne się pojawiły, w każdym razie nie ma tam czegoś takiego jak "parent"

  Co do pozostałych dwóch, a w przypadku trzeciego właściwie obowiązkowo, sprawdza się wstrzykiwanie na etapie pipeliny budującej artefakt. Wtedy masz jeden skrypt, który wszędzie ustawia wszystko. Alternatywnie możesz mieć właśnie Spring Cloud Config, lub jakieś usługi z nim zgodne i wstawiasz publiczne dane na poziomie deploymentu, a nie samego kodu.