Fase 04 — Operação de Produto
HITL #11 Aprovado Operations

Fase 04 — Operação de Produto

CI/CD pipeline, GMUD, deployment strategy, SLOs e DORA metrics.

CI/CD Pipeline — GitHub Actions

Pipeline com 6 jobs definido em .github/workflows/ci.yml. Adaptado para a stack real: npm (não pnpm), Fastify 5.0 (não tRPC/Next.js), SQLite3 in-memory para testes (não Supabase/PostgreSQL), Vitest (não Playwright).

Job 1
code-quality

Executa linting e verificação de tipos TypeScript em server e web.

  • lint — ESLint com regras padrão
  • typecheck server — tsc --noEmit no diretório server/
  • typecheck web — tsc --noEmit no diretório web/
Job 2 — depende de code-quality
unit-tests

Executa testes unitários via Vitest com SQLite3 in-memory.

  • server tests (Vitest) — 4 test files, 29 test cases cobrindo auth, pix, accounts, payments
  • web tests (Vitest) — testes de componentes React
Job 3 — depende de unit-tests
build

Build de produção do frontend React.

  • vite build — gera web/dist/ com arquivos estáticos otimizados (code splitting, tree shaking, minificação)
Job 4 — condicional (apenas branch main)
change-gate

Verifica aprovação da GMUD antes de permitir deploy em produção.

  • verify GMUD approval — checa se a GMUD correspondente está com status "Aprovada"
Job 5 — depende de build + change-gate
deploy-production

Deploy efetivo em produção.

  • install — npm ci com dependências de produção
  • build — compilação do servidor TypeScript
  • deploy server — upload e restart do processo Node.js via PM2
  • deploy web — upload dos arquivos estáticos (web/dist/)
  • migrations — execução de migrations do banco SQLite3
  • smoke test — verificação de health check pós-deploy
Job 6 — sempre executa
quality-gate

Gate final que verifica se todos os jobs anteriores passaram. Se qualquer job falhar, a pipeline é marcada como falhada.

GMUD-001 — Release Inicial

Gestão de Mudança
GMUD-001: Release Inicial — ECP Banco Digital v3.0 (MVP)
TipoNormal
StatusAprovada
RiscoBaixo (6/30)
Execução Planejada2026-03-05 10:00 BRT
Duração Estimada45 minutos
ComponentesFastify API, React SPA, SQLite3, GitHub Actions, Environment variables
RollbackSQLite backup + PM2 stop + static file replacement
docs/gmud/GMUD-001.md docs/gmud/registro.md

Estratégia de Deployment

API Server
Node.js + PM2

Processo Node.js gerenciado por PM2 em VPS/VM ou plataforma como Railway, Render ou Fly.io.

  • PM2 gerencia restart automático, logs e clustering
  • SQLite3 como arquivo local no mesmo servidor
  • Backup do banco antes de cada deploy
  • Rollback: PM2 rollback + restore do arquivo SQLite
Frontend SPA
Static Hosting

Arquivos estáticos (web/dist/) servidos via Vercel, Netlify, Cloudflare Pages ou pelo próprio Fastify.

  • Build gera HTML/CSS/JS otimizados
  • CDN para distribuição global
  • Cache headers para assets imutáveis
  • Fallback para SPA (index.html para todas as rotas)

Variáveis de Ambiente — Produção

VariávelPropósitoObrigatória
JWT_SECRETChave secreta para assinatura de tokens JWT — NUNCA usar valor padrãoSim
DATABASE_PATHCaminho para o arquivo SQLite em produçãoSim
PORTPorta da API (default: 3333)Sim
NODE_ENVproductionSim
VITE_API_URLURL da API em produção para build do frontendSim (build)
VERCEL_TOKENDeploy automático do frontend (se usar Vercel)Opcional

Service Level Objectives (SLOs)

Availability (API)
99.5%
Percentual de requisições respondidas com sucesso (excluindo 4xx do cliente). Medido por uptime monitoring.
Latency (P95)
< 500ms
95% das requisições de API respondidas em menos de 500ms. Medido via APM ou access logs.
Error Rate
< 1%
Taxa de respostas 5xx sobre o total de requisições. Exclui erros de validação (4xx).
Auth Success Rate
> 99%
Taxa de sucesso em tentativas de login com credenciais válidas. Falhas indicam problemas de infraestrutura.
LCP (Frontend)
< 2.5s
Largest Contentful Paint do dashboard após login. Medido via Core Web Vitals.
CI Pipeline Duration
< 10min
Tempo total do pipeline de CI (code-quality + tests + build). Meta de feedback rápido para desenvolvedores.

DORA Metrics — Targets (Elite Tier)

MétricaTargetComo Medir
Deployment Frequency On-demand (múltiplos por dia) Contagem de deploys em produção por dia/semana via GitHub Actions runs com status success na branch main.
Lead Time for Changes < 1 hora Tempo entre merge do PR na main e deploy completo em produção. Medido via timestamps do GitHub Actions.
Change Failure Rate < 5% Percentual de deploys que resultam em degradação de serviço, rollback ou hotfix. Medido via GMUD registry.
Time to Restore Service (MTTR) < 1 hora Tempo entre detecção de incidente e restauração do serviço. Medido via incident log com timestamps.

Links Úteis

📦 Guia de Instalação Completo 📊 Dashboard da Aplicação 📋 GMUD-001 Detalhada ⚙ Fase 03 — Delivery

HITL da Fase 04

HITLEscopoAgenteDecisão
#11Infraestrutura operacional (CI/CD pipeline, GMUD-001, guia de instalação, SLOs)OperationsAprovado

Artefatos Gerados

04-product-operation/ops-output.json 04-product-operation/hitl-11.json .github/workflows/ci.yml docs/gmud/GMUD-001.md docs/gmud/registro.md docs/INSTALACAO.md