#3 Spring Boot – application.properties – profile

Artykuł ten nawiązuje do poprzedniego wpisu, który dotyczy pliku właściwości application.properties. Dziś wpis dotyczący profili, czyli mechanizmu, który pomoże nam pracować z różnymi danymi. Możemy zdefiniować różne właściwości w zależności np. od tego na jakim środowisku chcemy pracować.

Tworzenie plików profilowych odbywa się poprzez dodanie pliku:

application-{profil}.properties

do naszego folderu z właściwościami, w moim przypadku jest to folder resources/config.
Załóżmy, że mamy dwa środowiska:

  • production
  • development

Na środowisku development wykorzystujemy bazę H2, która idealnie nadaje się do testowania i rozwoju aplikacji. Natomiast środowisko production wykorzystuje bazę MongoDB. W takim przypadku tworzymy dwa oddzielne pliki dla każdego profilu:

application.properties
application-development.properties
application-production.properties

Wyobraźmy sobie to jako klasy: application.properties jest to klasa bazowa, czyli są w niej właściwości, które chcemy, aby były propagowane w dół, czyli do naszych plików z konkretnymi profilami. Następnie pliki development oraz production są naszymi specyfikowanymi klasami, czyli są to pliki, które mają unikalne wartości.

Pliki te korzystają z właściwości, która odnosi się do bazy danych. Ustawiamy odpowiednie wartości:

application.properties

my.app.name = CodeCouple

application-development.properties

database.url = your_development_url_here

application-production.properties

database.url = your_production_url_here

Teraz z linii komend uruchamiamy naszą aplikację ustawiając interesujący nas profil:

-Dspring.profiles.active=development

Uruchomimy naszą aplikację z profilem development, który posiada w sobie URL do naszej bazy testowej. Uruchomiają się również właściwości zawarte w pliku nadrzędnym, czyli application.properties. Możecie teraz tworzyć własne profile dla odpowiednich aplikacji uniezależniając się od innych środowisk.

  • Warto wspomnieć, ze dobrą praktyką jest skonfigurowanie Mavena/Gradle by nie pchał do wynikowego WARa (jeśli wdrażamy plik na oddzielne serwery) wszystkich plików propertasów, tylko na podstawie aktualnego profilu wkładał do niego podstawowy plik z propertasami i plik dla profilu testowego/produkcyjnego. Pozwala to uniknąć koszmarnie trudnych do debugowania błędów uruchomienia.

    • Krzysztof Chruściel

      Witaj,
      Dzięki za trafną podpowiedź. Niestety nie miałem okazji pracować w architekturze microservisów więc ominęło mnie wdrażanie na oddzielne środowiska. Oczywiście masz rację i jest to dobre rozwiązanie, bo może się okazać że uruchomi się aplikacja ze złym profilem.

    • michaldo

      Czy mógłbyś rozwinąć ten komentarz? Wydaje mi się ‘profile’ oznacza raz profil Mavena/Gradla a raz Springa i przez to trudno mi zrozumieć ideę.
      Bo w moim rozumieniu właśnie powinno się pakować wszystkie zestawy propertiesów do WAR aby później aktywować właściwy przez profil Springa.

      • Cyprian

        To jest jeden z tematow spornych 😉
        Mi sie wydaje, ze podzial na profile powinien byc nastepujacy:
        application-mongo.properties
        application-h2.properties
        a url i hasla do bazy, to zewnetrzna konfiguracja. Ok, domyslna H2 moze byc wbudowana, jezeli operuje na pamieci. Jezeli przy tym jest spora roznica w bibliotekach, to build powinien generowac dwa artefakty z roznymi nazwami, czyli najlepiej dwa podprojekty.