Coordinando Deployments Entre Equipos

Los deployments modernos a menudo abarcan múltiples servicios, equipos y repositorios. Deployments no coordinados llevan a fallos de integración, downtime y culparse mutuamente. GitScrum ayuda a coordinar actividades de deployment para que todos sepan qué se está desplegando, cuándo y qué dependencias existen.

Desafíos de Deployment

Modelo de Coordinación de Deployment

Enfoque Release Train

ESTRUCTURA RELEASE TRAIN
════════════════════════

RELEASE: v2.5.0 (20 Marzo, 2024)
├── Release Manager: @sarah
├── Ventana de Deploy: 2:00-4:00 PM UTC
└── Ventana de Rollback: Hasta 6:00 PM UTC

SERVICIOS INCLUIDOS:
┌─────────────────────────────────────────────────────────┐
│  Servicio        │ Versión │ Equipo  │ Dependencias    │
├─────────────────────────────────────────────────────────┤
│  API Gateway     │ 1.8.0   │ Infra   │ Ninguna (primero│
│  Auth Service    │ 2.3.0   │ Backend │ API Gateway     │
│  User Service    │ 3.1.0   │ Backend │ Auth Service    │
│  Web Frontend    │ 4.5.0   │ Frontend│ Todos backends  │
│  Mobile Backend  │ 2.0.0   │ Mobile  │ User Service    │
└─────────────────────────────────────────────────────────┘

ORDEN DE DEPLOYMENT:
1. API Gateway (2:00 PM)
2. Auth Service (2:10 PM)
3. User Service (2:20 PM)
4. Mobile Backend (2:30 PM)
5. Web Frontend (2:40 PM)

Visualización de Dependencias

GRAFO DE DEPENDENCIAS DE DEPLOYMENT
═══════════════════════════════════

    ┌─────────────────┐
    │   API Gateway   │
    │ (Deploy 1ero)   │
    └────────┬────────┘
             │
    ┌────────┴────────┐
    ▼                 ▼
┌─────────┐     ┌───────────┐
│  Auth   │     │  Logging  │
│ Service │     │  Service  │
└────┬────┘     └───────────┘
     │
┌────┴────┐
▼         ▼
┌─────────┐     ┌─────────────┐
│  User   │────▶│   Mobile    │
│ Service │     │   Backend   │
└────┬────┘     └─────────────┘
     │
     ▼
┌─────────────┐
│     Web     │
│  Frontend   │
│(Deploy último)│
└─────────────┘

Checklist Pre-Deployment

Verificación de Readiness

CHECKLIST PRE-DEPLOYMENT
════════════════════════

CADA EQUIPO CONFIRMA:

[Equipo API Gateway]
- [x] Todos los PRs mergeados a release branch
- [x] Tests pasando en CI
- [x] Staging testeado y verificado
- [x] Migraciones de BD listas
- [x] Cambios de config documentados
- [x] Procedimiento de rollback documentado
- [x] Ingeniero on-call identificado
Status: LISTO ✓

[Equipo Auth Service]
- [x] Todos los PRs mergeados a release branch
- [x] Tests pasando en CI
- [ ] Staging testeado y verificado ⚠
- [x] Migraciones de BD listas
- [x] Cambios de config documentados
- [x] Procedimiento de rollback documentado
- [x] Ingeniero on-call identificado
Status: BLOQUEADO - Verificación staging pendiente

[Equipo User Service]
...

Reunión Go/No-Go

CHECKLIST GO/NO-GO
══════════════════

REUNIÓN: 1:30 PM UTC (30 min antes de deploy)
ASISTENTES: Release manager + team leads

CHECKLIST:
├── ¿Todos los servicios muestran status LISTO?
├── ¿Todas las verificaciones de staging completas?
├── ¿Todos los ingenieros on-call disponibles?
├── ¿Canales de comunicación listos?
├── ¿Dashboards de monitoreo abiertos?
├── ¿Soporte al cliente informado?
├── ¿Scripts de rollback testeados?
└── ¿Scripts de deploy listos?

DECISIÓN:
├── GO: Proceder con deployment
├── NO-GO: Abortar, reprogramar
└── PARCIAL: Deploy de subconjunto (con plan)

Ejecución del Deployment

Flujo de Comunicación

COMUNICACIÓN DE DEPLOYMENT
══════════════════════════

CANAL: #release-2.5.0

T-30 min:
├── @channel: Reunión Go/No-Go empezando
└── Decisión: GO ✓

T-0 (2:00 PM):
├── @channel: 🚀 Deployment empezando
├── @infra: Iniciando deploy API Gateway
└── Status: En Progreso

T+10 min:
├── @infra: ✓ API Gateway deployed, smoke tests pasando
├── @backend: Iniciando deploy Auth Service
└── Status: API Gateway ✓, Auth En Progreso

T+20 min:
├── @backend: ✓ Auth Service deployed
├── @backend: Iniciando deploy User Service
└── Status: API ✓, Auth ✓, User En Progreso

... (continuar para cada servicio)

T+45 min:
├── @channel: ✓ Todos los servicios deployed
├── @channel: Ejecutando verificación final
└── Status: Verificación En Progreso

T+50 min:
├── @channel: ✅ Release v2.5.0 completo
├── Todos los smoke tests pasando
├── Monitoreo se ve bien
└── Status: ÉXITO

Dashboard en Tiempo Real

DASHBOARD DE DEPLOYMENT
═══════════════════════

Release: v2.5.0 | Iniciado: 2:00 PM | Status: EN PROGRESO

┌─────────────────────────────────────────────────────────┐
│  Servicio        │ Status      │ Tiempo  │ Salud       │
├─────────────────────────────────────────────────────────┤
│  API Gateway     │ ✓ Completo  │ 8 min   │ ✓ Saludable │
│  Auth Service    │ ✓ Completo  │ 7 min   │ ✓ Saludable │
│  User Service    │ ⏳ Deploying│ 3 min   │ ⏳ Pendiente│
│  Mobile Backend  │ ⏸ Esperando │ -       │ -           │
│  Web Frontend    │ ⏸ Esperando │ -       │ -           │
└─────────────────────────────────────────────────────────┘

Logs | Métricas | Rollback

ACTIVIDAD ACTUAL:
├── User Service: Rolling update 3/5 pods
├── Esperando: Mobile Backend, Web Frontend
└── ETA: 15 minutos restantes

Procedimientos de Rollback

Plan de Rollback

PROCEDIMIENTOS DE ROLLBACK
══════════════════════════

TRIGGERS DE ROLLBACK:
├── Tasa de error > 1% por 2 minutos
├── Latencia P99 > 2x baseline
├── Funcionalidad crítica rota
├── Issue de integridad de datos detectado
└── Decisión del team lead

ORDEN DE ROLLBACK (inverso al deploy):
1. Web Frontend → v4.4.0
2. Mobile Backend → v1.9.0
3. User Service → v3.0.0
4. Auth Service → v2.2.0
5. API Gateway → v1.7.0

ESPECÍFICO POR SERVICIO:
──────────────────────────────────────
API Gateway:
Comando: kubectl rollout undo deployment/api-gateway
Verificar: curl https://api/health
Tiempo: ~2 min

Auth Service:
Comando: kubectl rollout undo deployment/auth
Verificar: curl https://auth/health
Tiempo: ~2 min
Base de datos: No se necesita rollback de migración
──────────────────────────────────────

Rollback Parcial

ESCENARIO ROLLBACK PARCIAL
══════════════════════════

SITUACIÓN: User Service causando errores
DECISIÓN: Rollback User Service, mantener otros

ACCIONES:
1. Parar más deployments
2. Rollback User Service
3. Verificar que Auth Service sigue funcionando
4. Verificar que API Gateway sigue funcionando
5. Comunicar status

POST-ROLLBACK:
├── Documentar qué falló
├── Arreglar y re-testear
├── Programar nuevo deployment
└── Post-mortem si es necesario

Tracking de Releases en GitScrum

Estructura de Tareas de Release

TAREA DE RELEASE EN GITSCRUM
════════════════════════════

PADRE: Release v2.5.0
├── Due: 20 Marzo, 2024
├── Owner: Release Manager
├── Labels: release, producción
└── Milestone: Release Q1 2024

TAREAS HIJAS:
├── [Infra] API Gateway v1.8.0
├── [Backend] Auth Service v2.3.0
├── [Backend] User Service v3.1.0
├── [Frontend] Web Frontend v4.5.0
├── [Mobile] Mobile Backend v2.0.0
├── [QA] Verificación pre-release
├── [Ops] Ejecución de deployment
└── [Ops] Monitoreo post-deployment

CHECKLIST EN PADRE:
├── [ ] Todos los servicios verificados en staging
├── [ ] Reunión Go/No-Go completa
├── [ ] Todos los equipos confirmaron listos
├── [ ] Deploy completo
├── [ ] Smoke tests pasando
├── [ ] Monitoreo verificado
└── [ ] Release notes publicadas

Mejores Prácticas

Para Coordinación de Deployments

1. Una fuente de verdad — Un lugar para status de deploy
2. Ownership claro — Release manager dirige
3. Orden definido — Dependencias respetadas
4. Ritmo de comunicación — Updates en cada milestone
5. Rollback listo — Siempre tener un plan B

Anti-Patrones

ERRORES DE COORDINACIÓN DE DEPLOYMENT:
✗ Sin orden de deployment definido
✗ Equipos desplegando independientemente
✗ Sin comunicación sobre timing
✗ Sin planes de rollback
✗ Sin verificación de dependencias
✗ Sin canal de comunicación dedicado

Soluciones Relacionadas

• Estrategias de continuous deployment
• Gestionando dependencias entre proyectos
• Coordinando desarrollo de features cross-funcionales