7 min leitura • Guide 537 of 877
Gestão de Projetos de Microservices
Arquiteturas de microservices distribuem complexidade entre múltiplos serviços gerenciados por diferentes times. A organização multi-projeto, rastreamento de dependências de serviços e recursos de visibilidade cross-team do GitScrum ajudam organizações a manter controle e coordenação em todo o desenvolvimento de microservices distribuído.
Modelos de Organização de Microservices
| Modelo | Melhor Para | Trade-offs |
|---|---|---|
| Projeto por serviço | Muitos serviços, times claros | Mais projetos para gerenciar |
| Projeto por domínio | Agrupamentos lógicos | Pode cruzar múltiplos times |
| Projeto compartilhado + labels | Poucos serviços, org pequena | Menos isolamento |
| Híbrido | Organizações complexas | Flexibilidade vs complexidade |
Organização de Projeto
OPÇÕES DE ORGANIZAÇÃO
OPÇÃO 1: PROJETO POR SERVIÇO
┌─────────────────────────────────────────────────┐
│ Workspace GitScrum │
│ ├── Projeto: user-service │
│ │ └── Owner: Time de Auth │
│ ├── Projeto: order-service │
│ │ └── Owner: Time de Pedidos │
│ ├── Projeto: payment-service │
│ │ └── Owner: Time de Pagamentos │
│ ├── Projeto: inventory-service │
│ │ └── Owner: Time de Inventário │
│ └── Projeto: notification-service │
│ └── Owner: Time de Plataforma │
│ │
│ Prós: Ownership claro, backlogs isolados │
│ Contras: Muitos projetos, overhead cross-proj. │
└─────────────────────────────────────────────────┘
OPÇÃO 2: PROJETO POR DOMÍNIO
┌─────────────────────────────────────────────────┐
│ Workspace GitScrum │
│ ├── Projeto: Domínio Cliente │
│ │ ├── user-service │
│ │ └── profile-service │
│ ├── Projeto: Domínio Comércio │
│ │ ├── order-service │
│ │ ├── payment-service │
│ │ └── cart-service │
│ └── Projeto: Domínio Operações │
│ ├── inventory-service │
│ ├── shipping-service │
│ └── notification-service │
│ │
│ Prós: Agrupamento lógico, menos projetos │
│ Contras: Pode cruzar limites de times │
└─────────────────────────────────────────────────┘
OPÇÃO 3: PROJETO COMPARTILHADO COM LABELS
┌─────────────────────────────────────────────────┐
│ Workspace GitScrum │
│ └── Projeto: Desenvolvimento da Plataforma │
│ Labels: │
│ ├── [svc:user] │
│ ├── [svc:order] │
│ ├── [svc:payment] │
│ ├── [svc:inventory] │
│ └── [svc:notification] │
│ │
│ Visualizações filtradas por serviço │
│ │
│ Prós: Simples, visão unificada │
│ Contras: Menos isolamento, precisa disciplina │
└─────────────────────────────────────────────────┘
Rastreamento de Features Cross-Service
ESTRUTURA DE EPIC CROSS-SERVICE
Epic: Feature de Checkout Express
├── Status: Em Desenvolvimento
├── Alvo: Sprint 8
├── Owner: @product-manager
│
├── Tarefas por Serviço:
│
├── [user-service] Métodos de pagamento salvos
│ ├── Armazenar tokens de pagamento criptografados
│ ├── API para adicionar método de pagamento
│ └── API para listar métodos de pagamento
│
├── [order-service] Criação rápida de pedido
│ ├── Endpoint de checkout express
│ ├── Aplicar método de pagamento salvo
│ └── Confirmação de pedido
│
├── [payment-service] Processamento de token
│ ├── Validar token de pagamento
│ ├── Processar pagamento tokenizado
│ └── Handling de webhook
│
├── [notification-service] Alertas de pedido
│ ├── Email de confirmação de pedido express
│ └── Push notification para mobile
│
└── [frontend] UI de Checkout
├── Seletor de pagamento salvo
├── Botão de checkout em um clique
└── Página de confirmação de pedido
Dependências:
├── payment-service → user-service (tokens)
├── order-service → payment-service (processamento)
└── frontend → todas as APIs completas
Coordenação Cross-Service
Dashboard de Serviços
VISÃO DE SAÚDE DOS SERVIÇOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SERVIÇO │ OWNER │ SPRINT │ SAÚDE │ DEPS │
│─────────────────┼────────────┼─────────┼───────┼─────────│
│ user-service │ Time Auth │ 92% │ 🟢 │ - │
│ order-service │ Time Ped. │ 78% │ 🟢 │ 2 │
│ payment-service │ Time Pag. │ 65% │ 🟡 │ 3 │
│ inventory-svc │ Time Inv. │ 88% │ 🟢 │ 1 │
│ notification │ Time Plat. │ 45% │ 🔴 │ 4 │
│ │
│ FEATURE CROSS-SERVICE ATIVA: │
│ ───────────────────────────── │
│ "Checkout Express" - 67% completo │
│ │
│ user-service: ████████████████████ 100% │
│ order-service: ████████████████░░░░ 80% │
│ payment-service: ████████████░░░░░░░░ 60% │
│ notification: ████████░░░░░░░░░░░░ 40% │
│ frontend: ██████████████░░░░░░ 70% │
│ │
└─────────────────────────────────────────────────────────────┘
Contratos de API
RASTREAMENTO DE CONTRATOS DE API:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONTRATOS PENDENTES DE APROVAÇÃO: │
│ ───────────────────────────────── │
│ • user-service/v2/payment-methods (novo) │
│ Consumer: payment-service │
│ Status: Em review │
│ │
│ • order-service/v1/express-checkout (mudança) │
│ Consumers: frontend, mobile-app │
│ Status: Breaking change - migração planejada │
│ │
│ CONTRATOS ATIVOS: │
│ ───────────────── │
│ ┌─────────────────┬────────────────┬──────────────┐ │
│ │ Provedor │ Consumer │ Versão │ │
│ ├─────────────────┼────────────────┼──────────────┤ │
│ │ user-service │ order-service │ v1.2 stable │ │
│ │ user-service │ frontend │ v1.2 stable │ │
│ │ payment-service │ order-service │ v1.0 stable │ │
│ │ inventory-svc │ order-service │ v1.1 stable │ │
│ └─────────────────┴────────────────┴──────────────┘ │
│ │
│ REGRAS: │
│ • Breaking changes precisam plano de migração │
│ • Consumers devem aprovar mudanças de contrato │
│ • Versioning semântico obrigatório │
│ │
└─────────────────────────────────────────────────────────────┘
Coordenação de Deployment
Ordem de Deployment
SEQUÊNCIA DE DEPLOYMENT CROSS-SERVICE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEATURE: Checkout Express │
│ │
│ ORDEM DE DEPLOYMENT: │
│ │
│ Fase 1: Serviços de dados (sem dependentes) │
│ ├── [1] user-service (métodos de pagamento) │
│ └── [2] inventory-service (validação de estoque) │
│ │
│ Fase 2: Serviços de negócio │
│ ├── [3] payment-service (depende de user-service) │
│ └── [4] order-service (depende de payment, inventory) │
│ │
│ Fase 3: Serviços de saída │
│ └── [5] notification-service (depende de order) │
│ │
│ Fase 4: Frontend │
│ └── [6] frontend (depende de todas as APIs) │
│ │
│ VALIDAÇÃO ENTRE FASES: │
│ • Health check de cada serviço │
│ • Contract tests passando │
│ • Smoke tests end-to-end │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE GESTÃO DE MICROSERVICES
════════════════════════════════════
ORGANIZAÇÃO:
☐ Modelo de projeto escolhido
☐ Ownership de serviço definido
☐ Convenção de nomes estabelecida
☐ Labels/tags configurados
COORDENAÇÃO:
☐ Syncs cross-team agendados
☐ Epics cross-service rastreados
☐ Dependências mapeadas
☐ Comunicação clara entre times
APIs:
☐ Contratos de API versionados
☐ Processo de review de mudanças
☐ Consumer approval para breaking changes
☐ Contract tests automatizados
DEPLOYMENT:
☐ Ordem de deployment documentada
☐ Feature flags para rollout gradual
☐ Rollback strategy por serviço
☐ Monitoramento cross-service
VISIBILIDADE:
☐ Dashboard de saúde dos serviços
☐ Métricas por serviço rastreadas
☐ Alertas configurados
☐ Portfolio view para liderança
Gestão efetiva de microservices transforma complexidade distribuída em entregas coordenadas - cada time autônomo mas alinhado.