Un deploy es el proceso de publicar un cambio (de código, contenido o configuración) desde el entorno donde se desarrolla hasta el entorno donde lo ven los usuarios finales. Sirve para evitar que un fallo durante el desarrollo afecte a la web pública.
Entornos típicos
- Local: la copia que tiene el desarrollador en su ordenador.
- Staging (a veces "preview" o "pre"): copia exacta de producción donde se prueban los cambios antes de publicar.
- Producción: la web pública, la que ven los usuarios reales.
Un cambio recorre estos entornos en orden. Saltar pasos es lo que más errores genera.
Cuánto tarda un deploy
Depende de la pila tecnológica. Tiempos orientativos:
- WordPress con plugin de migración (entre staging y producción): 5–15 minutos.
- Hosting moderno con git push automático (Cloud Run, Vercel, Netlify): 1–5 minutos.
- Servidor propio con CI/CD bien montado: 2–10 minutos.
- Servidor con despliegue manual (FTP, SSH a mano): 10–30 minutos según el alcance.
Después del deploy, hay que añadir el tiempo de propagación del CDN si lo hay (otro 1–5 minutos) y el tiempo en que las cachés de navegador antiguas expiren para los usuarios que ya tenían la web abierta.
Por qué a veces parece que el cambio no sale
Tres causas habituales:
- Caché del navegador. La página local del usuario sigue mostrando la versión antigua. Una recarga sin caché (
Cmd+Shift+R/Ctrl+F5) lo arregla. - Caché del servidor / CDN. Cloudflare, plugins de caché o el propio servidor mantienen una copia precalculada. Hay que purgarla.
- El cambio se hizo en staging y no se ha pasado a producción. Sucede cuando el flujo de trabajo separa entornos.
Por qué hay deploys que requieren ventana de mantenimiento
Algunos cambios necesitan reiniciar el servidor o migrar la base de datos. En esos casos la web puede quedar inaccesible 1–10 minutos. Se programan idealmente fuera del horario de uso intenso.