Spring Profiles — Configurando sua api por profiles.

E ai pessoal, tudo blz ? Ando meio sumido e acredito que todos nós sabemos o quanto a vida de cada um ta corrida, então sem muito bla bla bla, vou mais ao ponto do artigo.

Em algum momento, todo mundo acaba precisando que alguns parametros de configuração sejam diferentes em alguns cenários, o mais comum, é que mude de acordo com os ambientes que estamos rodando as aplicações. Para resolver esse problema, temos algumas formas, aqui vou apresentar uma muito difundida e bastante eficiente. Então bora falar dos profiles e como configurar eles para resolver esse problema.

Normalmente setamos as configurações em um arquivo chamado application.properties. É ele que o spring vai ler para saber alguns parametros como por exemplo: server.servlet.context-path, server.port, spring.datasource.url, spring.datasource.username e por ai vai…

Esses parametros tem valores diferentes com base no ambiente. Para dinamizar isso, vamos criar 1 arquivo properties para cada ambiente nosso da seguinte forma: application + (- referencia do ambiente).properties. Ex: application-prd.properties

Agora, no properties base (application.properties) vamos configurar de forma que quando ele seja lido, ele direcione para o properties com base em 1 parametro que será passado no build da aplicação. Ex: spring.profiles.active=@environment@

Feito isso, vamos configurar o pom para que no profile possamos receber esse parametro e assim o spring possa ser direcionada para ler o arquivo de properties adequado para o ambiente no empacotamento. Ex:

<profiles>

<profile>

<id>prd</id>

<properties>

<environment>prd</environment>

</properties>

<activation>

<activeByDefault>true</activeByDefault>

</activation>

</profile>

</profiles>

Onde você vê activeByDefault, é apenas para que caso não seja passado nenhum profile, seja carregado o que nós determinarmos como padrão. Por quê isso? Por quê em um ambiente de desenvolvimento real, é importante que o time de dev não tenha essa preocupação, ou seja, nós especificamos todos os ambientes, definimos o local ou dev como default e em nosso processo de deploy passamos os perfis apropriados para cada ambiente. Isso permite que o time de desenvolvimento possa simplesmente se preocupar em buildar(sem passar nada e de forma o mais simples possível) e escrever o código, afinal, somos nós da arquitetura e seniores que devemos ter esse trabalho. Não faz sentido prejudicar o desempenho do time ou honerar a produtividade com esse tipo de questão, concorda ?

Para que o maven filtre esses arquivos vamos adcionar as configurações no pom dentro do build:

<configuration>

<delimiters>

<delimiter>@</delimiter>

</delimiters>

<resources>

<resource>

<directory>src/main/resources</directory>

<filtering>true</filtering>

</resource>

</resources>

</configuration>

E finalmente para empacotar com base no profile basta passar o parametro no build e subir a aplicação. Ex: mvn package -Pprd / Ou na IDE — Run As / Maven Build… e no profile passar o valor que corresponde a referencia do properties, neste caso “prd”.

Então, é isso… Artigo simples, direto e acredito que bastante útil… Gostou, tem dúvidas ou críticas ? Comenta e vamos trocar experiências, vai ser massa.

Fui e até a próxima, flw !

Published By

Originally published at https://www.linkedin.com.