Configuração no Spring Boot: Dominando o application.yml e Perfis por Ambiente

O pesadelo do "Troca a URL antes de gerar o build"

Se você está começando, talvez já tenha passado por isso: para testar o projeto localmente, a URL do banco de dados na sua classe de configuração aponta para localhost:5432. Na hora de enviar para o servidor de teste da equipe, você entra no arquivo Java, altera manualmente para a URL de homologação, gera o build e envia. Dias depois, para subir para a nuvem de produção, você repete o processo, torcendo para não esquecer de mudar nenhuma senha.

Essa abordagem manual é extremamente perigosa. Além de abrir margem para que senhas de produção vazem no seu repositório do GitHub, ela viola um dos princípios mais importantes do desenvolvimento moderno: o seu artefato de build (o arquivo .jar) deve ser estritamente imutável.

O código que roda na sua máquina local precisa ser exatamente o mesmo que roda em produção. O que muda de um cenário para o outro são as configurações. No ecossistema Spring Boot, resolvemos isso usando a Externalized Configuration (Configuração Externalizada).

Properties vs. YML: Qual escolher?

Por padrão, quando criamos um projeto no Spring Initializr, ele nos entrega um arquivo chamado application.properties dentro da pasta src/main/resources. No entanto, a maioria dos projetos modernos de mercado prefere renomeá-lo para application.yml (YAML).

O motivo? Legibilidade e eliminação de repetição de texto. Veja a diferença prática ao configurar o Spring Data JPA e o servidor:

Usando application.properties (Verboso e repetitivo):

Properties

server.port=8080
spring.datasource.url=jdbc:postgresql://localhost:5432/meubanco
spring.datasource.username=postgres
spring.datasource.password=123456
spring.jpa.hibernate.ddl-auto=update

Usando application.yml (Hierárquico e limpo):

YAML

server:
  port: 8080

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/meubanco
    username: postgres
    password: 123456
  jpa:
    hibernate:
      ddl-auto: update

O formato YAML organiza as configurações em árvore (usando espaços para indentação), tornando arquivos complexos muito mais fáceis de ler e manter.

O Poder dos Spring Profiles (Perfis de Ambiente)

Imagine que no seu ambiente local (dev) você queira usar o banco de dados em memória H2 ou um container Docker local, com os logs da aplicação no nível mais detalhado (DEBUG). Porém, em produção (prod), você precisa usar um banco de dados robusto na nuvem (como o AWS RDS) e quer os logs limpos (INFO), exibindo apenas erros e avisos importantes.

O Spring Boot resolve isso usando Profiles (Perfis). Você pode criar arquivos específicos para cada ambiente seguindo a convenção de nomenclatura: application-{perfil}.yml.

Vamos estruturar o nosso projeto com três arquivos na pasta resources:

1. application-dev.yml (Configurações Locais)

server:
  port: 8080

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/db_dev
    username: alex_local
    password: password_local
  jpa:
    hibernate:
      ddl-auto: update

logging:
  level:
    org.springframework: DEBUG

2. application-prod.yml (Configurações de Produção — Sem senhas expostas!)

Em produção, nós nunca escrevemos senhas e URLs reais diretamente no arquivo. Em vez disso, usamos variáveis de ambiente que o sistema operacional ou o container (como o Docker/Kubernetes) vai injetar em tempo de execução usando a sintaxe ${NOME_DA_VARIAVEL:VALOR_PADRAO}.

server:
  port: 80 # Porta padrão web

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate # Jamais use update ou create em produção!

logging:
  level:
    org.springframework: INFO

3. application.yml (O arquivo central)

Este arquivo carrega as configurações que são globais (iguais para todos os ambientes) e define qual perfil deve rodar caso nenhum outro seja especificado.

spring:
  application:
    name: minha-api-produtos
  profiles:
    active: dev # Perfil padrão se ninguém avisar o contrário

Como ativar os perfis em tempo de execução?

Agora que você tem os seus perfis configurados, como avisar ao Spring Boot qual deles ele deve carregar na hora de rodar a aplicação? Existem três formas principais de fazer isso no mundo real:

1. Pelo terminal (Linha de comando)

Na hora de rodar o seu arquivo .jar gerado pelo Maven, você passa um argumento de sistema para a JVM:

Bash

java -jar minha-app.jar --spring.profiles.active=prod

2. Usando Variáveis de Ambiente (Excelente para Docker)

Se a sua aplicação roda dentro de um container Docker, você não precisa mexer no comando de inicialização. Basta passar a variável global do Spring no seu arquivo docker-compose.yml:

environment:
  - SPRING_PROFILES_ACTIVE=prod
  - DB_URL=jdbc:postgresql://meu-servidor-nuvem:5432/db_producao
  - DB_USERNAME=admin_prod
  - DB_PASSWORD=senha_ultra_secreta

3. Na sua IDE (Para testes locais)

Se você estiver usando o IntelliJ IDEA ou o Eclipse/STS, basta abrir as configurações de inicialização do projeto (Run/Debug Configurations) e digitar prod ou dev no campo Active Profiles.

Conclusão

Dominar a externalização de configurações e o uso de perfis eleva o nível de maturidade do seu desenvolvimento. Isso garante que a sua aplicação esteja pronta para rodar em qualquer provedor de nuvem de forma totalmente automatizada e segura.

Tratar chaves e comportamentos de ambiente como dados configuráveis, e não como código engessado, poupa horas de deploy e evita desastres em produção.