Spring Boot eksternalizuje konfigurację, dzięki czemu ten sam jar działa w każdym środowisku. Ustawienia umieszczasz w application.yml (lub .properties), wczytujesz je do kodu i zmieniasz zachowanie per środowisko za pomocą profili.
@Component
public class SearchService {
// Inject a single property; :20 is the fallback if it is missing.
@Value("${app.page-size:20}")
private int pageSize;
}
Dla wszystkiego poza jedną czy dwiema wartościami powiąż typowany obiekt zamiast rozsypywać @Value:
@Component
@ConfigurationProperties(prefix = "app") // binds app.* into these fields
public class AppProps {
private int pageSize;
private Map<String, Boolean> featureFlags;
// getters/setters — Boot relaxed-binds page-size -> pageSize
}
Daje ci to bezpieczeństwo typów, autouzupełnianie w IDE oraz walidację (dodaj @Validated + ograniczenia).
spring:
config:
activate:
on-profile: prod # only when 'prod' is active
server:
port: 80
Pliki takie jak application-dev.yml i application-prod.yml nakładają się na bazowy. Aktywuj jeden przez --spring.profiles.active=prod lub zmienną środowiskową SPRING_PROFILES_ACTIVE. Kolejność pierwszeństwa ma znaczenie: argumenty wiersza poleceń i zmienne środowiskowe nadpisują pliki, więc sekrety pozostają poza jarem.
Rekruter sprawdza, czy potrafisz dostarczyć jeden artefakt na dev/staging/prod bez przebudowywania. Wspomnienie o @ConfigurationProperties zamiast rozsypanego @Value oraz o zmiennych środowiskowych nadpisujących pliki dla sekretów pokazuje, że uruchamiałeś aplikacje Boot na produkcji, a nie tylko lokalnie.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj