Staging y reversiones
Dos hábitos separan un lanzamiento que se recupera con elegancia de uno que se convierte en pánico a medianoche: probar los cambios en algún lugar seguro antes de que lleguen a usuarios reales, y poder deshacer un mal despliegue al instante.
Un entorno de staging es simplemente una segunda copia de tu app — el mismo código, una separada, una separada (o desechable) — donde pruebas cosas antes de producción. La mayoría de los hosts hacen esto casi gratis: cada obtiene su propia URL de previsualización automáticamente, así puedes recorrer un cambio y compartirlo con alguien antes de fusionarlo. Úsalo especialmente para cualquier cosa que no puedas revertir fácilmente, como una migración de base de datos.
Imagina los tres entornos como una escalera que un cambio sube, con la reversión como la cuerda que hace caer producción directamente al último peldaño bueno:
dev ──▶ staging / preview ──▶ production
(laptop) (PR preview URL) (real users)
try click through live
anything share, verify ┌──────────────┐
│ deploy #42 │ ◀── actual (roto)
├──────────────┤
ROLLBACK│ deploy #41 │ ◀── último bueno conocido
│ ├──────────────┤
└──▶│ deploy #40 │
└──────────────┘
un comando / un clic = deshacer instantáneo
Un rollback (reversión) es tu botón de deshacer para toda la app. Como estas plataformas conservan cada despliegue anterior, volver a la última versión buena suele ser un comando o un clic en el panel:
# Cloudflare Pages: redesplegar un build conocido como bueno
wrangler pages deployment list
wrangler pages deployment rollback <DEPLOYMENT_ID>
# Vercel: promover un despliegue anterior de vuelta a producción
vercel rollback <DEPLOYMENT_URL>
Aprende este comando antes de necesitarlo, no durante la caída. Todo el sentido de la velocidad del vibe coding es que enviar cambios es barato — pero enviar barato solo se siente seguro cuando deshacer también es igual de barato.