Spring Boot externalisiert die Konfiguration, sodass dasselbe JAR in jeder Umgebung läuft. Du legst Einstellungen in application.yml (oder .properties) ab, liest sie in deinen Code ein und schaltest das Verhalten pro Umgebung mit Profilen um.
@Component
public class SearchService {
// Inject a single property; :20 is the fallback if it is missing.
@Value("${app.page-size:20}")
private int pageSize;
}
Für alles jenseits von ein oder zwei Werten binde ein typisiertes Objekt, statt @Value zu verstreuen:
@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
}
Das gibt dir Typsicherheit, IDE-Autovervollständigung und Validierung (füge @Validated + Constraints hinzu).
spring:
config:
activate:
on-profile: prod # only when 'prod' is active
server:
port: 80
Dateien wie application-dev.yml und application-prod.yml legen sich über die Basis. Aktiviere eines mit --spring.profiles.active=prod oder der Umgebungsvariable SPRING_PROFILES_ACTIVE. Die Reihenfolge der Priorität ist wichtig: Kommandozeilenargumente und Umgebungsvariablen überschreiben Dateien, sodass Secrets aus dem JAR herausbleiben.
Der Interviewer prüft, ob du ein Artefakt über Dev/Staging/Prod ausliefern kannst, ohne neu zu bauen. @ConfigurationProperties gegenüber verstreutem @Value zu erwähnen und dass Umgebungsvariablen Dateien für Secrets überschreiben, zeigt, dass du Boot-Apps in Produktion betrieben hast, nicht nur lokal.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden