Probar gratis
5 min lectura Guide 748 of 877

Mejores Prácticas de Migración de Base de Datos

Las migraciones de base de datos requieren planificación y ejecución cuidadosa. GitScrum ayuda a rastrear tareas de migración y coordinar deployments de forma segura.

Planificación de Migraciones

Estructura de Tarea de Migración

HISTORIA DE MIGRACIÓN DE BASE DE DATOS:
┌─────────────────────────────────────────────────────────────┐
│ DB-123: Agregar Tabla user_preferences                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ PROPÓSITO:                                                  │
│ Almacenar preferencias de notificación y display de usuario│
│ Requerido para: USER-456 (Feature de configuración)        │
│                                                             │
│ ═══════════════════════════════════════════════════════════ │
│                                                             │
│ SCRIPT DE MIGRACIÓN:                                        │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CREATE TABLE user_preferences (                         ││
│ │   id BIGSERIAL PRIMARY KEY,                            ││
│ │   user_id BIGINT NOT NULL REFERENCES users(id),        ││
│ │   preference_key VARCHAR(100) NOT NULL,                ││
│ │   preference_value JSONB NOT NULL DEFAULT '{}',        ││
│ │   created_at TIMESTAMP DEFAULT NOW(),                  ││
│ │   updated_at TIMESTAMP DEFAULT NOW(),                  ││
│ │   UNIQUE(user_id, preference_key)                      ││
│ │ );                                                      ││
│ │                                                         ││
│ │ CREATE INDEX idx_user_prefs_user ON                    ││
│ │   user_preferences(user_id);                           ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ SCRIPT DE ROLLBACK:                                         │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DROP TABLE IF EXISTS user_preferences;                  ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ ═══════════════════════════════════════════════════════════ │
│                                                             │
│ CHECKLIST:                                                  │
│ ☐ Script de migración revisado                            │
│ ☐ Script de rollback probado                              │
│ ☐ Ejecutado en staging exitosamente                       │
│ ☐ Impacto en performance evaluado                         │
│ ☐ Sin bloqueos de tabla en tablas grandes                 │
│ ☐ Ventana de deployment programada                        │
│ ☐ Monitoreo en su lugar                                   │
└─────────────────────────────────────────────────────────────┘

Evaluación de Riesgo

NIVELES DE RIESGO DE MIGRACIÓN:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ RIESGO BAJO (Luz verde):                                   │
│ • Agregar nueva tabla                                     │
│ • Agregar columna nullable                                │
│ • Agregar índice (si tabla pequeña)                      │
│ → Puede ejecutarse en cualquier momento                   │
│                                                             │
│ RIESGO MEDIO (Cuidado):                                    │
│ • Agregar índice a tabla grande                           │
│ • Modificar tipo de columna (compatible)                  │
│ • Agregar NOT NULL con default                            │
│ → Ejecutar durante bajo tráfico                           │
│ → Monitorear performance                                   │
│                                                             │
│ RIESGO ALTO (Precaución extra):                            │
│ • Modificar tipo de columna (incompatible)                │
│ • Remover columna                                          │
│ • Remover tabla                                            │
│ • Migraciones de datos grandes                            │
│ → Ventana de mantenimiento requerida                      │
│ → Equipo en standby para issues                           │
│ → Plan detallado de rollback                              │
│                                                             │
│ RIESGO CRÍTICO (Preparación completa):                     │
│ • Cambios de esquema en tablas enormes (100M+ filas)     │
│ • Cambios de foreign key                                   │
│ • Modificaciones de primary key                           │
│ → Ventana de mantenimiento extendida                      │
│ → Backup completo antes                                   │
│ → Aprobación ejecutiva                                    │
│ → War room durante ejecución                              │
└─────────────────────────────────────────────────────────────┘

Patrones de Migración Segura

Cambios Backward-Compatible

PATRONES DE MIGRACIÓN SEGURA:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ PATRÓN 1: EXPAND-CONTRACT                                   │
│                                                             │
│ OBJETIVO: Renombrar columna "name" a "full_name"          │
│                                                             │
│ ❌ RIESGOSO (un paso):                                     │
│ ALTER TABLE users RENAME name TO full_name;               │
│ → Rompe código viejo inmediatamente                       │
│                                                             │
│ ✅ SEGURO (expand-contract):                               │
│                                                             │
│ Paso 1 (Expand): Agregar nueva columna                    │
│ ALTER TABLE users ADD COLUMN full_name VARCHAR(255);      │
│                                                             │
│ Paso 2: Dual-write en código                              │
│ Escribir tanto a name como full_name                      │
│                                                             │
│ Paso 3: Backfill datos                                    │
│ UPDATE users SET full_name = name WHERE full_name IS NULL;│
│                                                             │
│ Paso 4: Cambiar lecturas a nueva columna                  │
│                                                             │
│ Paso 5: Dejar de escribir columna vieja                   │
│                                                             │
│ Paso 6 (Contract): Remover columna vieja (más tarde)     │
│ ALTER TABLE users DROP COLUMN name;                       │
│                                                             │
│ TIMELINE:                                                   │
│ ├── Migración 1 (agregar columna) - Sprint 1              │
│ ├── Deploy 1 (escribir ambas)                             │
│ ├── Migración 2 (backfill)                                │
│ ├── Deploy 2 (leer nueva)                                 │
│ ├── Deploy 3 (solo escribir nueva) - Sprint 2            │
│ └── Migración 3 (remover vieja) - Sprint 3               │
└─────────────────────────────────────────────────────────────┘

Checklist de Deployment

CHECKLIST DE DEPLOYMENT DE MIGRACIÓN:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ PRE-DEPLOYMENT:                                             │
│ ☐ Backup de base de datos completado                      │
│ ☐ Script de rollback probado en staging                   │
│ ☐ Ventana de mantenimiento comunicada                     │
│ ☐ Equipo de on-call notificado                            │
│ ☐ Monitoreo configurado                                   │
│                                                             │
│ DURANTE DEPLOYMENT:                                         │
│ ☐ Verificar conexiones de BD antes                        │
│ ☐ Ejecutar migración                                      │
│ ☐ Verificar schema post-migración                         │
│ ☐ Ejecutar smoke tests                                    │
│ ☐ Monitorear métricas de aplicación                       │
│                                                             │
│ POST-DEPLOYMENT:                                            │
│ ☐ Verificar funcionalidad de aplicación                   │
│ ☐ Monitorear errores por 1 hora                           │
│ ☐ Documentar cambios realizados                           │
│ ☐ Actualizar runbook si necesario                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Soluciones Relacionadas