O Spring Boot externaliza a configuração para que o mesmo jar rode em todos os ambientes. Você coloca as configurações em application.yml (ou .properties), as lê no seu código e alterna o comportamento por ambiente com profiles.
@Component
public class SearchService {
// Inject a single property; :20 is the fallback if it is missing.
@Value("${app.page-size:20}")
private int pageSize;
}
Para qualquer coisa além de um ou dois valores, faça o binding em um objeto tipado em vez de espalhar @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
}
Isso te dá segurança de tipo, autocompletar na IDE e validação (adicione @Validated + constraints).
spring:
config:
activate:
on-profile: prod # only when 'prod' is active
server:
port: 80
Arquivos como application-dev.yml e application-prod.yml se sobrepõem à base. Ative um com --spring.profiles.active=prod ou com a variável de ambiente SPRING_PROFILES_ACTIVE. A ordem de precedência importa: argumentos de linha de comando e variáveis de ambiente sobrepõem os arquivos, então os segredos ficam fora do jar.
O entrevistador está verificando se você consegue entregar um único artefato em dev/staging/prod sem recompilar. Mencionar @ConfigurationProperties em vez de @Value espalhado, e variáveis de ambiente sobrepondo arquivos para segredos, mostra que você já rodou apps Boot em produção, não apenas localmente.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar