9 min leitura • Guide 764 of 877
Desenvolvimento Backend com GitScrum
Desenvolvimento backend envolve APIs, bancos de dados e serviços que alimentam aplicações. GitScrum ajuda equipes a organizar trabalho backend com requisitos técnicos claros e dependências.
Estrutura de Tarefa Backend
Tarefas de Desenvolvimento de API
ESTRUTURA DE TAREFA DE ENDPOINT API:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA API BEM-ESTRUTURADA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Criar Endpoint de Exportação de Usuário ││
│ │ ││
│ │ ENDPOINT: ││
│ │ POST /api/v1/exports/users ││
│ │ ││
│ │ REQUEST: ││
│ │ { ││
│ │ "format": "csv" | "xlsx", ││
│ │ "filters": { ││
│ │ "created_after": "ISO date", ││
│ │ "status": "active" | "inactive" ││
│ │ } ││
│ │ } ││
│ │ ││
│ │ RESPONSE (202): ││
│ │ { ││
│ │ "export_id": "uuid", ││
│ │ "status": "processing", ││
│ │ "estimated_seconds": 30 ││
│ │ } ││
│ │ ││
│ │ ERROS: ││
│ │ 400: Formato ou filtros inválidos ││
│ │ 403: Sem permissão de exportação ││
│ │ 429: Muitas exportações pendentes ││
│ │ ││
│ │ IMPLEMENTAÇÃO: ││
│ │ ☐ Validar request ││
│ │ ☐ Enfileirar job em background ││
│ │ ☐ Criar registro de exportação ││
│ │ ☐ Retornar response assíncrona ││
│ │ ││
│ │ TESTE: ││
│ │ ☐ Testes unitários para validação ││
│ │ ☐ Teste de integração para fluxo completo ││
│ │ ☐ Teste de limite de taxa ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ELEMENTOS CHAVE: │
│ ✅ Contrato de API completo (request/response) │
│ ✅ Casos de erro documentados │
│ ✅ Checklist de implementação │
│ ✅ Requisitos de teste │
└─────────────────────────────────────────────────────────────┘
Trabalho de Banco de Dados
ESTRUTURA DE TAREFA DE BANCO DE DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE MIGRAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-150: Adicionar tabela exports ││
│ │ ││
│ │ SCHEMA: ││
│ │ ┌─────────────────────────────────────────────────────┐││
│ │ │ exports │││
│ │ ├─────────────────────────────────────────────────────┤││
│ │ │ id: UUID (PK) │││
│ │ │ user_id: UUID (FK → users) │││
│ │ │ type: VARCHAR(50) │││
│ │ │ format: VARCHAR(10) │││
│ │ │ status: VARCHAR(20) [pending, processing, done] │││
│ │ │ file_url: TEXT (nullable) │││
│ │ │ error_message: TEXT (nullable) │││
│ │ │ expires_at: TIMESTAMP │││
│ │ │ created_at: TIMESTAMP │││
│ │ │ updated_at: TIMESTAMP │││
│ │ └─────────────────────────────────────────────────────┘││
│ │ ││
│ │ ÍNDICES: ││
│ │ ☐ user_id (filtrar por usuário) ││
│ │ ☐ status (processar pending) ││
│ │ ☐ expires_at (job de limpeza) ││
│ │ ││
│ │ ROLLBACK: ││
│ │ DROP TABLE exports; ││
│ │ ││
│ │ NOTAS DE DEPLOYMENT: ││
│ │ • Sem downtime esperado (nova tabela) ││
│ │ • Executar em staging primeiro ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CHECKLIST DE MIGRAÇÃO: │
│ ☐ Arquivo de migração criado │
│ ☐ Rollback testado │
│ ☐ Deployment staging verificado │
│ ☐ Deployment produção planejado │
└─────────────────────────────────────────────────────────────┘
Design de API
Contratos de API Primeiro
DESENVOLVIMENTO CONTRACT-FIRST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FLUXO DE TRABALHO: │
│ │
│ 1. DESIGN CONTRATO DE API │
│ Frontend + Backend concordam com forma │
│ Documentam em OpenAPI/Swagger │
│ │
│ 2. DESENVOLVIMENTO PARALELO │
│ Frontend: Constrói contra API mock │
│ Backend: Implementa API real │
│ │
│ 3. INTEGRAÇÃO │
│ Conecta API real │
│ Corrige casos extremos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TAREFA DE DESIGN DE CONTRATO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ API-001: Design Contrato API de Exportação ││
│ │ ││
│ │ Participantes: Líder FE, Líder BE, PM ││
│ │ ││
│ │ Deliverables: ││
│ │ ☐ Spec OpenAPI para endpoints de exportação ││
│ │ ☐ Exemplos request/response ││
│ │ ☐ Responses de erro documentadas ││
│ │ ☐ Abordagem de paginação (se necessário) ││
│ │ ││
│ │ Decisões necessárias: ││
│ │ ☐ Assíncrono vs sync para exportações grandes ││
│ │ ☐ Abordagem de armazenamento de arquivo ││
│ │ ☐ Estratégia de limite de taxa ││
│ │ ││
│ │ Output: Spec de API aprovado ││
│ │ Habilita: BE-100, FE-200 para iniciar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFÍCIOS: │
│ ✅ Equipes trabalham em paralelo │
│ ✅ Discordâncias de contrato pegas cedo │
│ ✅ Frontend pode usar mocks gerados │
│ ✅ Documentação de API como subproduto │
└─────────────────────────────────────────────────────────────┘
Desenvolvimento de Serviço
Trabalho de Arquitetura de Serviço
TRABALHO DE NÍVEL DE SERVIÇO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE NOVO SERVIÇO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-200: Criar Serviço Worker de Exportação ││
│ │ ││
│ │ PROPÓSITO: ││
│ │ Worker em background que processa jobs de exportação ││
│ │ ││
│ │ ARQUITETURA: ││
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ││
│ │ │ API │───>│ Queue │───>│ Worker │ ││
│ │ │ │ │ (Redis) │ │ │ ││
│ │ └─────────┘ └─────────┘ └────┬────┘ ││
│ │ │ ││
│ │ ┌─────▼─────┐ ││
│ │ │ S3 │ ││
│ │ └───────────┘ ││
│ │ ││
│ │ IMPLEMENTAÇÃO: ││
│ │ ☐ Classe processadora de job ││
│ │ ☐ Query de banco para exportação ││
│ │ ☐ Geração CSV/XLSX ││
│ │ ☐ Upload S3 ││
│ │ ☐ Atualizações de status ││
│ │ ☐ Tratamento de erro ││
│ │ ☐ Lógica de retry ││
│ │ ││
│ │ ESCALA: ││
│ │ • Múltiplos workers podem processar em paralelo ││
│ │ • Jobs são idempotentes ││
│ │ • Timeout: 10 minutos por job ││
│ │ ││
│ │ MONITORAMENTO: ││
│ │ ☐ Métricas sucesso/falha de job ││
│ │ ☐ Histograma de tempo de processamento ││
│ │ ☐ Alerting de profundidade de queue ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Testando Backend
Requisitos de Teste
ESTRATÉGIA DE TESTE BACKEND:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NÍVEIS DE TESTE: │
│ │
│ TESTES UNITÁRIOS: │
│ • Lógica de negócio │
│ • Validação │
│ • Utilitários │
│ • Rápido, isolado │
│ │
│ TESTES DE INTEGRAÇÃO: │
│ • Endpoints de API │
│ • Operações de banco de dados │
│ • Chamadas de serviço externo (mocked) │
│ • Testar banco, queries reais │
│ │
│ TESTES E2E: │
│ • Fluxos críticos │
│ • Serviços reais (staging) │
│ • Menos, mais caros │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REQUISITOS DE TESTE DE TAREFA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Criar Endpoint de Exportação de Usuário ││
│ │ ││
│ │ TESTES UNITÁRIOS: ││
│ │ ☐ Validação de request ││
│ │ ☐ Construção de filtro ││
│ │ ☐ Criação de job de exportação ││
│ │ ││
│ │ TESTES DE INTEGRAÇÃO: ││
│ │ ☐ POST /api/v1/exports/users (caminho feliz) ││
│ │ ☐ Formato inválido retorna 400 ││
│ │ ☐ Permissão faltando retorna 403 ││
│ │ ☐ Limite de taxa excedido retorna 429 ││
│ │ ☐ Job enfileirado corretamente ││
│ │ ││
│ │ COBERTURA DE TESTE: ││
│ │ Mínimo: 80% para código novo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINIÇÃO DE CONCLUÍDO: │
│ ☐ Testes unitários passam │
│ ☐ Testes de integração passam │
│ ☐ Cobertura atende mínimo │
│ ☐ Pipeline CI verde │
└─────────────────────────────────────────────────────────────┘
Tratamento de Erro
Estratégia de Erro
REQUISITOS DE TRATAMENTO DE ERRO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUTURA DE RESPONSE DE ERRO: │
│ { │
│ "error": { │
│ "code": "VALIDATION_ERROR", │
│ "message": "Formato de exportação inválido", │
│ "details": { │
│ "field": "format", │
│ "allowed": ["csv", "xlsx"] │
│ } │
│ } │
│ } │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TRATAMENTO DE ERRO EM TAREFAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Tratamento de Erro ││
│ │ ││
│ │ Erros de validação (400): ││
│ │ ☐ Retornar erros de nível de campo ││
│ │ ☐ Incluir valores permitidos ││
│ │ ││
│ │ Erros de auth (401/403): ││
│ │ ☐ Mensagem clara sobre o que é necessário ││
│ │ ☐ Não vazar info interno ││
│ │ ││
│ │ Limite de taxa (429): ││
│ │ ☐ Incluir header retry-after ││
│ │ ☐ Explicar limite ││
│ │ ││
│ │ Erros de servidor (500): ││
│ │ ☐ Log erro completo internamente ││
│ │ ☐ Retornar mensagem genérica para cliente ││
│ │ ☐ Incluir ID de request para debugging ││
│ │ ││
│ │ Tratamento de timeout: ││
│ │ ☐ Definir timeouts razoáveis ││
│ │ ☐ Retornar 504 se excedido ││
│ │ ☐ Tornar operações resumíveis onde possível ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LOGGING: │
│ • Logs estruturados (JSON) │
│ • ID de request em todos logs │
│ • Contexto de usuário (quem, o quê, quando) │
│ • Métricas de performance (duração) │
└─────────────────────────────────────────────────────────────┘