Spring Boot: desenvolver vários serviços em local

Atualizado: 14 de agosto de 2026

Um serviço Spring Boot na tua máquina é um problema resolvido: executas a classe principal e estás a trabalhar. Cinco, a falar entre si, com um Kafka e um Postgres por baixo, é por onde se vai a manhã.

O que realmente custa tempo

• A ordem. Quem se regista tem de estar de pé antes de quem o procura, e «de pé» significa a responder a /actuator/health, não ter um PID.
• As portas. Dois serviços trazem 8080 por omissão. O terceiro que arrancas encontra uma ocupada e cabe-te descobrir qual.
• Os URLs. Cada serviço tem uma propriedade que aponta a outro —app.catalog.url e as suas quinze irmãs— e apontar três para outro sítio significa editar ficheiros de que depois há que lembrar-se de não comitar.
• A infraestrutura. Kafka, Redis e PostgreSQL, levantados sempre igual, com os topics e o esquema que os serviços esperam.
• As tuas próprias bibliotecas. Uma biblioteca partilhada em que além disso precisas de mexer significa mvn install, subir a versão e confiar que mais ninguém levou o snapshot.

O que o Aseptic faz com isso

O Aseptic deteta um serviço Spring Boot pelo seu manifesto —Maven ou Gradle— e sabe como o arrancar, onde está o seu endpoint de saúde e como lhe passar configuração. A configuração é injetada ao arrancar, como propriedades de sistema -D ou variáveis de ambiente, por isso os URLs entre serviços são reescritos sem tocar no application.yml nem em nada do teu repositório. Nada para comitar, nada de que lembrar-se de reverter.

Um cenário agrupa os serviços de um fluxo e arranca-os por ordem de dependência, esperando pela saúde e não pelo processo. As portas que colidem são remapeadas sozinhas, e o valor novo é o que se conta aos restantes serviços. Kafka, Redis e PostgreSQL levantam em Docker, geridos pela app.

Para cada dependência escolhes onde se resolve: outro serviço que tenhas aberto em local, o vosso ambiente partilhado na nuvem —com a VPN, se é assim que lá chegam— ou um mock. Essa escolha é por dependência, não por ambiente, por isso «estes dois em local e o resto contra a nuvem» é uma terça-feira normal e não um exercício de configuração.

Bibliotecas sem as publicar

Se a mudança abrange um serviço e uma biblioteca tua, o Aseptic constrói a biblioteca e liga-a em quem a consome onde o Maven e o Gradle a procuram —o teu repositório local ~/.m2— e pode reconstruí-la e voltar a ligá-la quando muda. Não edita o pom.xml nem o build.gradle do consumidor, e desligar desfaz só o que fez.

O que não faz

Não substitui a tua build. O Maven e o Gradle ficam exatamente onde estão, e o Aseptic chama-os. Não executa um cluster de Kubernetes, por isso se o que precisas de verificar é um probe, um ingress ou um sidecar, esta é a ferramenta errada —um cluster local é a certa—. E precisa de Docker para a infraestrutura comum, por isso é preciso ter o Docker Desktop ou um motor Docker instalado.

Está em beta pública, publica-se para Windows, macOS e Linux, e é grátis para uso pessoal.

Onde fica isto face aos suspeitos do costume

Se os teus serviços já têm imagens e manifestos que manténs, o Tilt ou o Skaffold mantêm o ciclo local com a forma de produção, em troca de uma build e um deploy a cada mudança. A página de alternativas ao Docker Compose abre o campo inteiro, e o comparativo amplo cobre o Compose e o Kubernetes local diretamente.

Há equivalentes desta página para Quarkus e para Node.

← Voltar ao início