Las migraciones de Laravel que rompen producción — y los patrones seguros que usamos en su lugar

Hay una categoría de migraciones de Laravel que siempre funciona en staging y rompe frecuentemente producción: renombrar una columna, soltar una columna, cambiar un tipo, añadir un NOT NULL a una tabla poblada. El patrón es el mismo en cada caso — el cambio de esquema requiere un lock completo de tabla o un cutover coordinado con el deploy, y los defaults de Laravel no te dan ninguno.

Esta es la disciplina de migración-segura que aplicamos a cada cliente Laravel gestionado con una base de datos no trivial.

El rename seguro en dos pasos

// Migración 1 — deploy
Schema::table('users', function (Blueprint $t) {
    $t->string('email_address')->nullable();   // añadir la nueva columna
});
// Backfill vía un queue job, no en la migración
 
// Migración 2 — desplegada solo después de completar el backfill
Schema::table('users', function (Blueprint $t) {
    $t->string('email_address')->nullable(false)->change();
    $t->dropColumn('email');                   // soltar la antigua columna
});

La regla: cada «rename» o «cambio de tipo» se convierte en dos despliegues con un backfill en medio. El primer despliegue añade la nueva columna. El código de aplicación aprende a leer y escribir ambas. Un job en background hace el backfill. Tras completarse el backfill y la app ya no leer la columna vieja, el segundo despliegue la quita.

El artículo completo cubre:

• La trampa «funciona en la pequeña tabla de staging» (los locks de tabla escalan con el row count)
• Disciplina --pretend — leer el SQL real antes de ejecutarlo
• Herramientas de cambio de esquema online (gh-ost, pt-online-schema-change) para los casos donde las migraciones de Laravel no bastan
• Hacer backfill vía queue jobs, no vía migraciones
• La plantilla de migración que estandarizamos para clientes
• Estrategia de rollback cuando una migración ya ha corrido y el deploy falla

Háblanos si tu última ventana de migración fue más larga de lo que debería.