Configuração e Execução Local
Variáveis de ambiente, banco de dados e como rodar o backend localmente.
Variáveis de ambiente
O perfil dev (application-dev.properties) espera as seguintes variáveis:
| Variável | Uso |
|---|---|
BACKEND_PORT | Porta do servidor (default 8080; o perfil dev sobrescreve pra 8083) |
DEV_SUPABASE_URL, DEV_SUPABASE_USERNAME, DEV_SUPABASE_PASSWORD | Conexão JDBC com o Postgres (hospedado no Supabase) |
DEV_MONGO_USER, DEV_MONGO_PASSWORD, DEV_MONGO_HOST, DEV_MONGO_PORT, DEV_MONGO_DB | Conexão com o MongoDB usado pela Auditoria |
DEV_SUPABASE_STORAGE_URL, DEV_SUPABASE_SERVICE_ROLE_KEY | Upload de imagens de roteiro de vaga (ver Clientes) |
DEV_SUPABASE_STORAGE_BUCKET_VACANCY | Nome do bucket (default vacancy-roadmaps) |
JWT_GENERATOR_SIGNATURE_SECRET | Segredo HS256 usado para assinar os tokens (ver Usuários e Autenticação); mínimo de 32 caracteres |
Essas variáveis não têm arquivo .env versionado no repo — precisam ser exportadas no ambiente ou
configuradas na IDE antes de rodar.
Banco de dados
- PostgreSQL — schema gerenciado via Flyway (
src/main/resources/db/migration), migrations versionadas (V0001__...sql,V0002__...sql, ...) mais um script repetível (R__Populate_Users_Roles_Permissions.sql) que popula usuários, papéis e permissões padrão a cada deploy.hibernate.hbm2ddl.auto=validate— o Hibernate não cria/altera tabelas sozinho, só valida contra o schema que o Flyway já aplicou. - MongoDB — usado exclusivamente para o log de Auditoria (append-only, sem migration formal).
Rodando localmente
./mvnw mn:run
# ou, com o profile dev explícito:
./mvnw mn:run -Dmicronaut.environments=devCom o servidor no ar, a documentação interativa (Swagger) fica disponível sem autenticação em
/swagger-ui.
Segurança por padrão
micronaut.security.intercept-url-map define as regras globais: /swagger*/** e
/gnoqcore/v1/auth/** são anônimas, todo o resto exige autenticação (isAuthenticated()) —
autorização fina por permissão vem depois, via @RequiresPermission em cada endpoint (ver
Permissões).
Deploy (Azure Pipelines)
pipelines/azure-pipelines.yml — dispara em push nas branches develop e main, três estágios:
- Build:
mvn clean package -DskipTests(⚠️ os testes não rodam no CI hoje) e publica o.jarcomo artefato. - DeployDev: só roda se a branch for
develop. Copia o.jarvia SSH pro servidor de dev. - DeployProd: só roda se a branch for
main. Mesma coisa, servidor de produção.
O deploy em si (pipelines/templates/deploy.yml, compartilhado entre dev/prod) segue o padrão de
releases com symlink, comum em deploys via SSH sem orquestrador:
- Copia o
.jarpra uma pastareleases/release_<timestamp>/nova - Atualiza o symlink
currentpra apontar pra essa pasta - Reinicia o
systemdservice (gnoq-core-backend-dev/gnoq-core-backend-prod) - Espera até 10 tentativas (3s cada) o serviço ficar
active - Se falhar: reaponta o symlink
currentde volta pro release anterior e reinicia — rollback automático, sem intervenção manual
Cada ambiente é isolado por basePath (/opt/gnoq-core/dev e /opt/gnoq-core/prod) e por endpoint SSH
próprio (gnoq-core-ssh-dev / gnoq-core-ssh-prod), configurados diretamente no Azure DevOps.