7 min leitura • Guide 508 of 877
Como Gerenciar Projetos de Desenvolvimento de Microserviços
Arquiteturas de microserviços requerem coordenação de múltiplos times trabalhando em serviços independentes com interdependências complexas. Dependências cross-projeto do GitScrum, rastreamento de contratos de API e recursos de visibilidade multi-time ajudam organizações a gerenciar a complexidade inerente ao desenvolvimento de sistemas distribuídos.
Desafios de Projetos de Microserviços
| Desafio | Impacto | Solução |
|---|---|---|
| Dependências de serviço | Trabalho bloqueado | Mapeamento de dependências |
| Breaking changes de API | Falhas de integração | Testes de contrato |
| Coordenação de deployment | Outages | Orquestração de deployment |
| Features cross-team | Overhead de comunicação | Épicos compartilhados |
| Ownership de serviço | Responsabilidade não clara | Modelo de ownership claro |
Organização de Projeto
ESTRUTURA DE PROJETO DE MICROSERVIÇOS
Opção 1: Projeto por Serviço
┌─────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ │
│ │ User Service│ │Order Service│ │ Payment │ │
│ │ Projeto │ │ Projeto │ │ Service │ │
│ │ │ │ │ │ Projeto │ │
│ │ Time: Auth │ │ Time: Orders│ │ Time: Pay│ │
│ └─────────────┘ └─────────────┘ └──────────┘ │
│ │
│ Épico Cross-Projeto: "Feature Checkout Mobile"│
│ └── Tarefas distribuídas para cada projeto │
│ │
└─────────────────────────────────────────────────┘
Opção 2: Projeto por Domínio
┌─────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Plataforma E-Commerce │ │
│ │ │ │
│ │ Swimlanes por Serviço: │ │
│ │ ├── User Service │ │
│ │ ├── Order Service │ │
│ │ ├── Payment Service │ │
│ │ └── Notification Service │ │
│ │ │ │
│ │ Labels: [user-svc] [order-svc] [payment]│ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Mapeamento de Dependências
RASTREAMENTO DE DEPENDÊNCIAS CROSS-SERVIÇO
FEATURE: Adicionar Express Checkout
┌─────────────────────────────────────────────────┐
│ Épico: Express Checkout │
│ │
│ Dependências (sequência importa): │
│ │
│ Sprint N: │
│ └── [API Design] Contrato da API Payment │
│ └── [API Design] Contrato da API Order │
│ │
│ Sprint N+1: │
│ ├── [User Service] Métodos de pagamento salvos │
│ └── [Payment Service] Endpoint de tokenização │
│ └── Depende de: API Design completo │
│ │
│ Sprint N+2: │
│ ├── [Order Service] Fluxo de express checkout │
│ │ └── Depende de: Payment tokenização │
│ └── [Frontend] UI de checkout │
│ └── Depende de: API Order Service │
│ │
│ Sprint N+3: │
│ └── [Integração] Testes end-to-end │
│ └── Depende de: Todos serviços completos │
└─────────────────────────────────────────────────┘
Gestão de Contratos de API
WORKFLOW DE CONTRATO DE API
1. FASE DE DESIGN
┌─────────────────────────────────────────────────┐
│ Tarefa: Design da API Payment Tokenization │
│ │
│ Entregáveis: │
│ ☐ OpenAPI spec em repo compartilhado │
│ ☐ Review com times consumidores │
│ ☐ Testes de contrato definidos │
│ ☐ Assessment de breaking change │
│ │
│ Revisores: Times Order Service, Frontend │
└─────────────────────────────────────────────────┘
2. FASE DE IMPLEMENTAÇÃO
┌─────────────────────────────────────────────────┐
│ Tarefa Producer: Implementar API Payment │
│ ├── Implementar endpoints conforme spec │
│ ├── Rodar testes de contrato │
│ └── Deploy para staging │
│ │
│ Tarefa Consumer: Integrar com API Payment │
│ ├── Bloqueado até: API em staging │
│ ├── Implementar cliente │
│ ├── Rodar testes de contrato │
│ └── Testes de integração │
└─────────────────────────────────────────────────┘
3. FASE DE VALIDAÇÃO
┌─────────────────────────────────────────────────┐
│ Contract Tests (CI/CD): │
│ ├── Producer publica contrato │
│ ├── Consumers verificam contra contrato │
│ └── Falha se contrato quebrado │
└─────────────────────────────────────────────────┘
Coordenação de Deployment
ESTRATÉGIAS DE DEPLOYMENT DE MICROSERVIÇOS
DEPLOYMENT INDEPENDENTE:
┌─────────────────────────────────────────────────┐
│ Cada serviço deploya independentemente │
│ ├── Sem coordenação necessária │
│ ├── Requer compatibilidade backward/forward │
│ └── Melhor para times maduros │
│ │
│ Quando usar: │
│ • Mudanças não-breaking │
│ • Serviço isolado │
│ • Feature flags disponíveis │
└─────────────────────────────────────────────────┘
DEPLOYMENT COORDENADO:
┌─────────────────────────────────────────────────┐
│ Múltiplos serviços deployam em sequência │
│ ├── Order: API changes primeiro │
│ ├── Payment: Consume nova API │
│ └── Frontend: Usa nova funcionalidade │
│ │
│ Quando usar: │
│ • Breaking changes de API │
│ • Features cross-serviço │
│ • Migrações de dados │
└─────────────────────────────────────────────────┘
Plano de Rollout Cross-Serviço
ROLLOUT DE FEATURE CROSS-SERVIÇO
Feature: Express Checkout
SEQUÊNCIA DE DEPLOYMENT:
┌─────────────────────────────────────────────────┐
│ │
│ T+0: Deploy Payment Service │
│ ├── Nova API de tokenização (flag off) │
│ └── Verificar: API responde, sem erros │
│ │
│ T+1h: Deploy Order Service │
│ ├── Integração com Payment (flag off) │
│ └── Verificar: Fluxo existente funciona │
│ │
│ T+2h: Deploy Frontend │
│ ├── Nova UI de checkout (flag off) │
│ └── Verificar: UI existente funciona │
│ │
│ T+4h: Habilitar flag interno (dogfooding) │
│ └── Verificar: Fluxo E2E funciona │
│ │
│ T+24h: Rollout gradual (10% → 50% → 100%) │
│ └── Monitorar: Erros, latência, métricas │
│ │
└─────────────────────────────────────────────────┘
Ownership e Responsabilidade
MODELO DE OWNERSHIP DE SERVIÇO
OWNERSHIP CLARO:
┌─────────────────────────────────────────────────┐
│ Serviço: Payment Service │
│ ├── Time Owner: Payments Team │
│ ├── Tech Lead: @maria │
│ ├── On-call: Rotação payments-oncall │
│ └── Slack: #payments-service │
│ │
│ Responsabilidades: │
│ ├── Desenvolvimento e manutenção │
│ ├── On-call e incidentes │
│ ├── Documentação de API │
│ └── Comunicação de breaking changes │
└─────────────────────────────────────────────────┘
DECISÕES DE API:
┌─────────────────────────────────────────────────┐
│ Quem decide mudanças de API? │
│ ├── Minor changes: Time owner │
│ ├── Breaking changes: Aprovação de consumers │
│ └── Arquitetura: Guild de arquitetura │
│ │
│ Processo: │
│ 1. RFC em repo compartilhado │
│ 2. Review de times afetados │
│ 3. Período de feedback (1 semana) │
│ 4. Decisão e implementação │
└─────────────────────────────────────────────────┘
Métricas de Saúde de Serviços
DASHBOARD DE SAÚDE DE MICROSERVIÇOS
POR SERVIÇO:
┌─────────────────────────────────────────────────┐
│ Service Latency Error% Deploy/Week │
│ ───────────────────────────────────────────── │
│ User 45ms 0.1% 3 │
│ Order 120ms 0.3% 5 │
│ Payment 80ms 0.2% 2 │
│ Notification 30ms 0.5% 4 │
└─────────────────────────────────────────────────┘
CROSS-SERVIÇO:
┌─────────────────────────────────────────────────┐
│ E2E Checkout Latency: 450ms (P95) │
│ E2E Success Rate: 98.5% │
│ Inter-service Calls/min: 125,000 │
│ Contract Test Pass Rate: 100% │
└─────────────────────────────────────────────────┘