6 min lectura • Guide 505 of 877
Cómo Gestionar Proyectos de Desarrollo de Microservicios
Las arquitecturas de microservicios requieren coordinar múltiples equipos trabajando en servicios independientes con interdependencias complejas. Las dependencias cross-proyecto, tracking de contratos de API y funciones de visibilidad multi-equipo de GitScrum ayudan a las organizaciones a gestionar la complejidad inherente en el desarrollo de sistemas distribuidos.
Desafíos de Proyectos de Microservicios
| Desafío | Impacto | Solución |
|---|---|---|
| Dependencias de servicio | Trabajo bloqueado | Mapeo de dependencias |
| Cambios breaking de API | Fallos de integración | Testing de contratos |
| Coordinación de deploy | Outages | Orquestación de deploy |
| Features cross-equipo | Overhead de comunicación | Epics compartidos |
| Propiedad de servicio | Responsabilidad poco clara | Modelo claro de ownership |
Organización del Proyecto
ESTRUCTURA DE PROYECTO DE MICROSERVICIOS
Opción 1: Proyecto por Servicio
┌─────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ │
│ │Servicio User│ │Servicio │ │ Servicio │ │
│ │ Proyecto │ │Order Proy. │ │ Payment │ │
│ │ │ │ │ │ Proyecto │ │
│ │ Team: Auth │ │ Team: Orders│ │ Team: Pay│ │
│ └─────────────┘ └─────────────┘ └──────────┘ │
│ │
│ Epic Cross-Proyecto: "Feature Checkout Móvil" │
│ └── Tareas distribuidas a cada proyecto servicio│
│ │
└─────────────────────────────────────────────────┘
Opción 2: Proyecto por Dominio
┌─────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Plataforma E-Commerce │ │
│ │ │ │
│ │ Swimlanes por Servicio: │ │
│ │ ├── Servicio User │ │
│ │ ├── Servicio Order │ │
│ │ ├── Servicio Payment │ │
│ │ └── Servicio Notification │ │
│ │ │ │
│ │ Etiquetas: [user-svc] [order-svc] [pay] │ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Mapeo de Dependencias
TRACKING DE DEPENDENCIAS CROSS-SERVICIO
FEATURE: Agregar Express Checkout
┌─────────────────────────────────────────────────┐
│ Epic: Express Checkout │
│ │
│ Dependencias (secuencia importa): │
│ │
│ Sprint N: │
│ └── [Diseño API] Contrato API de Payment │
│ └── [Diseño API] Contrato API de Order │
│ │
│ Sprint N+1: │
│ ├── [User Service] Métodos de pago guardados │
│ └── [Payment Service] Endpoint tokenización │
│ └── Depende de: Diseño API completo │
│ │
│ Sprint N+2: │
│ ├── [Order Service] Flujo express checkout │
│ │ └── Depende de: Tokenización de Payment │
│ └── [Frontend] UI de Checkout │
│ └── Depende de: API de Order Service │
│ │
│ Sprint N+3: │
│ └── [Integración] Testing end-to-end │
│ └── Depende de: Todos servicios completos │
└─────────────────────────────────────────────────┘
Gestión de Contratos de API
FLUJO DE TRABAJO DE CONTRATOS API
1. FASE DE DISEÑO
┌─────────────────────────────────────────────────┐
│ Tarea: Diseñar API de Tokenización de Payment │
│ │
│ Entregables: │
│ ☐ Spec OpenAPI en repo compartido │
│ ☐ Review con equipos consumidores │
│ ☐ Contract tests definidos │
│ ☐ Evaluación de breaking change │
│ │
│ Revisores: Equipos Order Service, Frontend │
└─────────────────────────────────────────────────┘
2. FASE DE IMPLEMENTACIÓN
┌─────────────────────────────────────────────────┐
│ Tarea Productor: Implementar API de Payment │
│ ├── Implementar endpoints según spec │
│ ├── Ejecutar contract tests │
│ └── Deploy a staging │
│ │
│ Tarea Consumidor: Integrar con API de Payment │
│ ├── Bloqueado hasta: API en staging │
│ ├── Implementar cliente │
│ └── Ejecutar tests de integración │
└─────────────────────────────────────────────────┘
3. PROTOCOLO DE BREAKING CHANGE
┌─────────────────────────────────────────────────┐
│ Si se necesita breaking change: │
│ │
│ Paso 1: Anunciar en canal #api-changes │
│ Paso 2: Crear tarea de migración para consumers│
│ Paso 3: Versionar la API (v1 → v2) │
│ Paso 4: Soportar ambas versiones en migración │
│ Paso 5: Deprecar versión vieja con deadline │
│ Paso 6: Remover versión vieja después deadline │
└─────────────────────────────────────────────────┘
Coordinación de Deploy
DEPLOY MULTI-SERVICIO
CHECKLIST DE DEPLOY PARA FEATURE X:
┌─────────────────────────────────────────────────┐
│ │
│ Pre-Deploy: │
│ ☐ Todos los servicios pasando tests │
│ ☐ Contract tests en verde │
│ ☐ Migraciones de base de datos listas │
│ ☐ Feature flags en lugar │
│ ☐ Procedimientos de rollback documentados │
│ │
│ Orden de Deploy: │
│ 1. ☐ Database migrations │
│ 2. ☐ Payment Service (dependencia) │
│ 3. ☐ Order Service │
│ 4. ☐ User Service │
│ 5. ☐ Frontend │
│ │
│ Post-Deploy: │
│ ☐ Smoke tests ejecutados │
│ ☐ Métricas verificadas │
│ ☐ Feature flag activado gradualmente │
│ ☐ Monitoreo durante 1 hora │
│ │
│ Rollback si: │
│ ☐ Tasa error > 1% │
│ ☐ Latencia > 2x baseline │
│ ☐ Excepciones críticas detectadas │
└─────────────────────────────────────────────────┘
Mejores Prácticas
- Mapear dependencias explícitamente antes de planificar sprints
- Contract testing obligatorio para APIs entre servicios
- Ownership clara de cada servicio
- Comunicación regular entre equipos de servicios
- Deploy independiente cuando sea posible
- Monitoreo centralizado para visibilidad cross-servicio
- Documentar APIs como ciudadanos de primera clase
- Feature flags para rollouts controlados