cross-cutting
Configuration & Profiles
Externalize config (URLs, credentials, feature flags) and activate environment-specific beans via profiles.
Configuration that changes between environments — database URLs, credentials, feature flags, third-party endpoints — must live outside the compiled code, or you end up rebuilding the application to deploy it to staging versus production. Externalised configuration and profiles are Spring Boot's answer: the same artifact runs everywhere, and what differs is supplied from the environment.
A power adapter kit — same device, different plugs depending on the country.
Key Concepts
1
Spring Boot reads configuration from many sources in a defined precedence order — command-line arguments, environment variables, application.properties or application.yml, and profile-specific files — with later sources overriding earlier ones, so an environment variable can override a baked-in default without a rebuild. You bind values into beans either with @Value("${...}") for a single property or, better for grouped settings, with @ConfigurationProperties, which maps a whole tree of properties onto a typed object and supports validation. Profiles handle environment-specific variation: activating a profile (via spring.profiles.active) loads application-{profile}.yml and enables any beans annotated @Profile("..."), so you can have a real mail sender in production and a no-op in tests, or different datasource settings per environment, all selected at startup rather than compiled in.
application.propertiesapplication.yml@Value("${...}")@ConfigurationPropertiesspring.profiles.active
2
The themes worth raising are keeping secrets out of source control — externalising them to environment variables or a secrets manager rather than committing credentials — and preferring typed @ConfigurationProperties over scattered @Value injections because it groups related settings, validates them, and documents the configuration surface in one class. Understanding the precedence order is the practical key: it is what lets the same build behave correctly across every environment and what you reason about when a property "isn't taking effect."
@ConfigurationProperties@Value