Deploy

REGRA CRÍTICA: Nunca usar docker compose up diretamente. Sempre usar bash deploy.sh. Esta regra já derrubou o sistema 4 vezes (04-14, 04-17, 04-20 x2).

Por que o deploy.sh é obrigatório

O deploy.sh faz três coisas que o docker compose up não faz:

1. Busca a CLERK_PUBLISHABLE_KEY do Azure Key Vault antes do build do frontend. Essa variável é injetada na imagem no momento do build — se não estiver presente, o Clerk não funciona.

2. Usa os 3 arquivos de compose obrigatoriamente:

   -f docker-compose.yml
   -f docker-compose.override.yml
   -f docker-compose.labels.yml

   Sem o labels.yml, o Traefik perde o roteamento → 404 em produção.

3. Tagueia as imagens com timestamp e atualiza o .env — sem isso, o Docker pode usar a imagem antiga do registry.

Comandos disponíveis

# Rebuild completo (backend + frontend) + restart
bash deploy.sh

# Só rebuild e restart do frontend
bash deploy.sh frontend

# Só rebuild e restart do backend
bash deploy.sh backend

# Só rebuild e restart da landing page
bash deploy.sh landing

# Restart sem rebuild (usa imagem já buildada)
bash deploy.sh --restart

Fluxo completo de um deploy

deploy.sh
  │
  ├── Carrega /home/crm/.crm-secrets (AZURE_CLIENT_SECRET)
  │
  ├── [Se frontend] Busca CLERK_PUBLISHABLE_KEY do Key Vault
  │     └── docker exec backend node -e "SecretClient.getSecret('NEXT-PUBLIC-CLERK-PUBLISHABLE-KEY')"
  │
  ├── docker build --no-cache
  │     ├── frontend → crm-frontend:local-20250523-143022
  │     └── backend  → crm-backend:local-20250523-143022
  │
  ├── Atualiza .env com FRONTEND_IMAGE e BACKEND_IMAGE
  │
  ├── docker compose -f ... -f ... -f ... up -d --force-recreate
  │
  ├── Health check backend (GET /health, timeout 60s)
  │
  ├── Health check frontend (HTTP status != 000/502/503, timeout 60s)
  │
  ├── Verificação de imagens (confirma que container usa a imagem esperada)
  │
  └── docker image prune -f (limpa imagens dangling)

Quando usar cada comando

Situação	Comando
Mudança no backend (código, .env, migrations)	bash deploy.sh backend
Mudança no frontend (código, estilos, componentes)	bash deploy.sh frontend
Mudança em variáveis de ambiente que afetam build	bash deploy.sh (full)
Container morreu, precisa subir sem rebuildar	bash deploy.sh --restart
Mudança na landing page	bash deploy.sh landing

Deploy de migrations

Migrations são aplicadas automaticamente pelo entrypoint do backend:

CMD ["sh", "-c", "npx prisma migrate deploy && node dist/main.js"]

Basta fazer bash deploy.sh backend — o Prisma aplica as migrations pendentes antes de iniciar.

Deploy emergencial

Se o sistema caiu e precisa subir rapidamente:

# 1. Ver o que está rodando
docker ps | grep crm-galdix

# 2. Tentar restart sem rebuild primeiro (mais rápido)
bash deploy.sh --restart

# 3. Se não funcionar, rebuild completo
bash deploy.sh

# 4. Ver logs se ainda não subir
docker logs crm-galdix-backend-1 --tail 50
docker logs crm-galdix-frontend-1 --tail 50

Tempo esperado de deploy

Operação	Tempo
Backend rebuild	~2–3 min
Frontend rebuild	~3–5 min
Full deploy (ambos)	~6–8 min
Restart sem rebuild	~30s

Onde o deploy.sh fica

/home/crm/app/deploy.sh

O script deve ser executado a partir do diretório /home/crm/app (o cd está embutido no script).