Os Profiles ou perfis de execução de uma aplicação nos permitem diferentes configurações de acordo com o ambiente ou objetivo da execução. Por exemplo, precisamos de um banco de dados H2 localmente, com certo usuário e senha, mas em produção usamos um Postgres com outro usuário e senha. Ainda, podemos ter algum teste que usa uma terceira configuração, por exemplo, com um banco desconfigurado para simular um erro de execução.
Para estas variações de execução temos os Profiles. Esta é uma funcionalidade central do Spring e está presente tanto no SpringBoot quanto diretamente na raiz do Spring. Com ela podemos criar diferentes arquivos de configuração para nossa aplicação, e quando “executamos” podemos informar qual “profile” queremos utilizar.
Dada a explicação inicial, vamos ver como “criar” profiles e como utilizá-los:
1.Criando profiles
Cabe dizer que o nome dos profiles não são predefinidos e você pode ser criativo, mas usualmente eles são simples e alfanuméricos. Exemplos de bons nomes de profiles: “local”, “testes”, “testes-kafka”, “producao” ou mesmo “cliente345”. Dito isso, há basicamente duas formas de “definir” esses nomes de profiles:
1.1.Limitando uso de SpringBeans com Profiles
Por exemplo, supondo que temos um SpringBean (classe Java com algum stereotype) de configuração de banco Postgresql, que só queremos que seja executado em Produção. Podemos utilizar nesta classe a anotação @Profile indicando que queremos que funcione somente no profile “prod”:
@Component
@Profile("prod")
public class ConfigurePostgresConfig {
//Método de configuração omitido...
}
Neste caso esse “SpringBean” será carregado para o contexto do Spring somente se o profile for especificamente “prod”. Ainda é possível colocar uma lista de profiles nesta anotação ou fazer lógica como “OU”, “E” ou “NEGAÇÃO” mas não abordaremos esses exemplos aqui. Olhe a documentação adicional para esses casos.
1.2.Diferenciando configurações com Profiles
No caso de configurações podemos criar arquivos para cada cenário, e eles podem ser no formato “properties” ou “yaml”. Porém, não basta criarmos o arquivo, ele deve seguir um padrão:
application-{nomeprofile}.{properties ou yml}
Exemplos de nomes válidos: application-prod.yaml, application-local.properties, application-teste-integrado.yaml. Nestes casos os profiles são “prod”, “local” e “teste-integrado” respectivamente.
OBS:
- Ainda há o arquivo “application.yaml” ou “application.properties” considerado o profile padrão (default).
- A extensão “yaml” também pode ser escrita apenas “yml”.
- Com algumas configurações no projeto o prefixo “application” pode ser substituído por “bootstrap”. Neste caso, por exemplo podemos ter um arquivo “bootstrap-local.yml” também válido.
2.Utilizando profiles
Para fazermos nossa aplicação ler e utilizar um destes arquivos de configuração, ou mesmo considerar o profile para descartar um “SpringBean” da configuração temos de indicar qual (ou quais) profiles queremos utilizar na inicialização da aplicação. Podemos fazer isso de algumas formas:
2.1.Através do application.yml/application.properties
Esses arquivos, por serem o “profile padrão” SEMPRE são lidos, então dentro deles podemos declarar uma propriedade “spring.profiles.active” indicando qual profile também deve ser considerado. Exemplo:
arquivo application.properties (profile padrão):
spring.profiles.active=local
arquivo application-local.properties (profile local):
logging.level.root=debug
2.2.Através de variável de ambiente
Podemos definir uma variável tanto na nossa IDE quanto no próprio sistema operacional denominada “SPRING_PROFILES_ACTIVE”. Por exemplo, no linux, ao configurarmos atráves de export SPRING_PROFILES_ACTIVE=dev
estamos exportando no bash uma variável ativando o profile “dev”.
2.3.Através de parâmetros de execução
Podemos ainda definir um parâmetro “spring.profiles.active”. Os parâmetros de JVM normalmente são passados utilizando “-D”, então no caso ficaria: -Dspring.profiles.active=dev
para ativar o profile “dev”.
Ainda é possível fixar essa variável “spring.profiles.active” programaticamente no Java, como propriedade de projetos Maven ou Gradle. Em todos os casos irá funcionar, resta escolher a melhor forma de configurar essa propriedade.
Materiais em vídeo:
Fizemos uma seleção dentre os vídeos para ajudá-lo a entender mais sobre o assunto:
Mais informações:
Seguem materiais adicionais, lembrando que sempre a documentação oficial é a melhor fonte, seguido de outros sites e fóruns: