Mi protocolo de deploy a producción

𝗗𝗲𝗽𝗹𝗼𝘆𝗮𝗿 𝘀𝗶𝗻 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹𝗼 𝗲𝘀 𝗵𝗮𝗰𝗲𝗿 𝗿𝘂𝗹𝗲𝘁𝗮 𝗿𝘂𝘀𝗮 𝗰𝗼𝗻 𝗽𝗿𝗼𝗱𝘂𝗰𝗰𝗶ó𝗻 🔥

Sin orden fijo, cada deploy es un intento de suerte. Y producción no es el lugar para improvisar. 😅

En mis primeros despliegues de 𝗟𝘂𝗺𝗶𝗻𝗛𝗲𝗮𝗹𝘁𝗵 en el VPS aprendí esto a las malas: un paso salteado, una variable que no actualizó, y el servicio caído un viernes en la noche. 💻

Hoy tengo un 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹𝗼 fijo con tres fases:

🟡 𝗣𝗿𝗲-𝗱𝗲𝗽𝗹𝗼𝘆

✅ Revisar y comparar variables de entorno (.env)

✅ Validar el build en local

✅ Correr los tests

✅ Revisar scripts de 𝗺𝗶𝗴𝗿𝗮𝗰𝗶ó𝗻 𝗱𝗲 𝗕𝗗 antes de ejecutarlos

✅ Crear backup del estado actual del servidor y de la base de datos

🔵 𝗗𝗲𝗽𝗹𝗼𝘆

✅ Pull de la rama correcta en el servidor

✅ Instalar dependencias

✅ Ejecutar 𝘀𝗰𝗿𝗶𝗽𝘁𝘀 𝗱𝗲 𝗺𝗶𝗴𝗿𝗮𝗰𝗶ó𝗻 𝗱𝗲 𝗕𝗗 (si aplica)

✅ Correr el build — o el 𝘀𝗰𝗿𝗶𝗽𝘁 𝘀𝗲𝗺𝗶-𝗮𝘂𝘁𝗼𝗺á𝘁𝗶𝗰𝗼 de deploy

✅ Reiniciar el servicio (PM2 / systemd / nginx)

🟢 𝗣𝗼𝘀𝘁-𝗱𝗲𝗽𝗹𝗼𝘆

✅ Smoke test en rutas críticas

✅ Verificar que las migraciones de BD aplicaron correctamente

✅ Prueba funcional desde el cliente (app, sistema web, flujo completo del usuario)

✅ Revisar logs en tiempo real los primeros 5 minutos

✅ Confirmar que el monitoreo está activo

Y dos 𝗺á𝘅𝗶𝗺𝗮𝘀 que aplico siempre 👇

🚫 𝗘𝘃𝗶𝘁𝗮𝗿 𝗱𝗲𝗽𝗹𝗼𝘆𝗮𝗿 𝗲𝗻 𝘃𝗶𝗲𝗿𝗻𝗲𝘀. Si algo se rompe, tienes el fin de semana por delante. No vale la pena.

🕐 𝗗𝗲𝗽𝗹𝗼𝘆𝗮𝗿 𝗲𝗻 𝗯𝗮𝗷𝗮 𝗰𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝗰𝗶𝗮. Menos usuarios activos = menos impacto si algo falla mientras el sistema estabiliza.

Un checklist no es burocracia. Es la diferencia entre un deploy tranquilo 🚀 y una noche de emergencia.

¿Tienes tu propio protocolo de deploy? ¿Qué máxima agregarías tú? 👇

¡Sigan volando, Campeones! ✈️