# SLA Separacao

Aplicacao TanStack Start/Node.js para registro de coleta de pedidos, usando SQL Server.

## Desenvolvimento local

```sh
cp .env.example .env   # preencha com as credenciais do seu ambiente
npm install
npm run dev
```

O `npm install` roda um `postinstall` que reaplica automaticamente o patch em `patches/` (veja "Patches de dependências" abaixo).

## Build de produção local

Para validar um build antes de mandar pro Jenkins:

```sh
npm run build
node .output/server/index.mjs
```

É o mesmo comando que o `Dockerfile` roda no container final.

## Estrutura de deploy

Este repositorio ja possui a base para subir o app como servico separado:

- [Dockerfile](Dockerfile)
- [Jenkinsfile](Jenkinsfile)
- [k8s/deployment.yaml](k8s/deployment.yaml)
- [k8s/service.yaml](k8s/service.yaml)
- [k8s/hpa.yaml](k8s/hpa.yaml)
- [k8s/secret.example.yaml](k8s/secret.example.yaml)
- [k8s/create-secret.sh](k8s/create-secret.sh)

## Variaveis obrigatorias

O app precisa destas variaveis no ambiente de deploy (veja `.env.example`):

- `DB_HOST`
- `DB_PORT`
- `DB_NAME`
- `DB_USER`
- `DB_PASSWORD`
- `DB_ENCRYPT`
- `DB_TRUST_SERVER_CERT`
- `DB_SERVER_NAME`
- `SESSION_SECRET`

## Aplicando o secret no cluster

Com `kubectl` configurado para o namespace `ci-cd`, exporte as variaveis acima e rode:

```sh
NAMESPACE=ci-cd SECRET_NAME=sla-separacao-env \
DB_HOST=... DB_PORT=... DB_NAME=... DB_USER=... DB_PASSWORD=... \
DB_ENCRYPT=... DB_TRUST_SERVER_CERT=... DB_SERVER_NAME=... SESSION_SECRET=... \
./k8s/create-secret.sh
```

O script usa `kubectl apply` (idempotente) e nunca grava os valores em disco.

## Patches de dependências

`patches/@tanstack+start-server-core+*.patch` corrige um bug no `@tanstack/start-server-core`: a lib cria o middleware de CSRF padrão de forma incondicional ao carregar o módulo, o que colide com um import circular gerado pelo `nitro` no build de produção e quebra toda requisição (`createCsrfMiddleware is not a function`). O patch adia essa criação para dentro de uma função. Ele é reaplicado automaticamente pelo `postinstall` a cada `npm install`; se atualizar `@tanstack/start-server-core`, confira se o patch ainda se aplica.

## Antes do deploy

Voce precisa validar estes pontos no ambiente da empresa:

1. O cluster/servidor consegue acessar `10.77.77.10:1433`.
2. O registry `10.77.77.41:5000` aceita push da nova imagem.
3. O namespace `ci-cd` e o padrao de deploy pelo Jenkins continuam validos.
4. A `nodePort` `30310` esta livre, ou voce vai trocar para outra.
5. Existe uma forma de expor esse novo servico externamente depois do `Service`.

## Observacoes

- O app atual usa SQL Server direto, sem API intermediaria.
- O deploy criado aqui e separado do app Django existente.
- O repositório nao guarda o secret real de producao; ele deve ser criado no cluster.
- O build de produção usa o preset `node-server` do nitro (não Cloudflare) — o `Dockerfile` roda `node .output/server/index.mjs` diretamente, então o preset precisa continuar assim.