--- title: "Despliegues WordPress sin downtime con Trellis: atomía, rollback y hooks" url: "https://helloblog.io/es/despliegues-wordpress-sin-downtime-con-trellis/" date: "2025-10-02" modified: "2026-01-20" author: "Carlos Rodríguez" language: "es_ES" categories: ["Ecosistema WordPress"] tags: ["Bedrock", "Deploy", "Roots", "Trellis", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/5/2026/01/featured-2-1024x572.png" excerpt: "Si alguna vez has subido cambios a producción y has rezado para que nadie entre justo en ese minuto, esto es para ti. Trellis aplica despliegues atómicos a WordPress para publicar releases sin cortes y con rollback inmediato." --- # Despliegues WordPress sin downtime con Trellis: atomía, rollback y hooks En el ecosistema WordPress sigue siendo sorprendentemente común que un despliegue implique “pisar” archivos en producción: FTP, un `rsync` rápido o algún sistema del hosting que actualiza el código in-place. Funciona… hasta que no funciona. El patrón clásico: el sitio sirve durante unos segundos (o minutos) una mezcla de archivos antiguos y nuevos y, con mala suerte, rompes el front, el admin o una integración crítica. Trellis (del stack de Roots) trae una idea muy estándar en desarrollo moderno: **despliegues sin downtime** mediante una estrategia *atomic deployment* (despliegue atómico). Lo interesante es que no necesitas “casarte” con Trellis para todo tu flujo: hay equipos que lo usan únicamente como herramienta de despliegue de sitios WordPress basados en Bedrock, manteniendo su entorno local favorito (Valet, Lando, DDEV, etc.) y desplegando incluso en proveedores gestionados. ## Qué significa realmente “zero downtime” en un WordPress Un despliegue sin downtime busca que el sitio se mantenga **totalmente accesible y funcional durante todo el proceso**. La diferencia no está en “subir más rápido”, sino en evitar el estado intermedio peligroso: ese momento en el que el servidor web puede encontrar una plantilla nueva que llama a una función que aún no existe, o un archivo borrado que todavía se referencia. La clave es preparar una release completa **en aislamiento** y, cuando está lista, hacer un cambio instantáneo para que el servidor empiece a servir esa release. Sin mezclas. Sin ventanas de inconsistencia. ## El problema típico de despliegue en WordPress (y por qué se rompe) Los enfoques más habituales suelen caer en alguna de estas categorías: - **Subidas por FTP/SFTP:** vas copiando cambios y sobrescribiendo archivos. El tiempo de subida (y la latencia) hace que el sitio quede expuesto a combinaciones incoherentes de versiones. - **Sincronización tipo `rsync`:** más rápido que FTP, pero conceptualmente igual: actualizas archivos sobre el árbol activo mientras el tráfico sigue entrando. - **Sistemas basados en plugins del hosting:** cómodos, pero a menudo siguen actualizando el código in-place y, si algo falla, el rollback no es inmediato (o ni siquiera existe como operación simple). El denominador común: **durante el despliegue tu sitio puede servir una mezcla de viejo y nuevo**, no tienes un rollback de un solo comando y tus usuarios pueden ver errores justo en la ventana del despliegue. ## Cómo lo resuelve Trellis: despliegues atómicos e inmutables Trellis aplica una estrategia de despliegue atómico: cada publicación crea una **release completa en un directorio nuevo**. Esa release es **inmutable**: una vez desplegada, sus archivos no se modifican in-place. Cuando todo está preparado, Trellis cambia un symlink y el servidor pasa a servir la nueva release de forma instantánea. ### Estructura de directorios: el symlink `current` como pieza central En un servidor desplegado con Trellis, la estructura típica se parece a esto: ``` /srv/www/example.com/ ├── current/ # Symlink a la release activa ├── releases/ # Historial de releases desplegadas │ ├── 20250930124530/ │ ├── 20250930083045/ │ └── 20250930141622/ # La más reciente ├── shared/ # Archivos compartidos entre releases │ └── uploads/ └── logs/ ``` Tu servidor web (Nginx, por ejemplo) apunta siempre a `current/`. Pero `current/` no es un directorio “real”: es un enlace simbólico al directorio de una release concreta dentro de `releases/`. ### Qué pasa cuando ejecutas `trellis deploy production` A alto nivel, el despliegue sigue un pipeline claro (y separado del árbol activo): 1. **Initialize:** verifica/crea la estructura base y genera un nuevo directorio de release con timestamp. 2. **Update:** clona el código más reciente desde tu repositorio Git a un directorio fuente temporal, fuera del sitio en vivo. 3. **Prepare:** copia el contenido necesario a la nueva release. 4. **Build:** ejecuta `composer install` para descargar dependencias PHP. 5. **Share:** enlaza recursos persistentes (por ejemplo, `uploads`) desde `shared/` hacia la release nueva. 6. **Finalize:** actualiza el symlink `current` para apuntar a la release recién preparada. El cambio visible para el usuario ocurre en el último paso: un instante estás sirviendo `releases/20250930124530` y al siguiente `releases/20250930141622`. No hay un periodo “a medias”. ## La base de datos: el punto que no puedes ignorar Importante: que el código se despliegue sin downtime no implica automáticamente que tus cambios de **base de datos** estén cubiertos. Según la documentación de despliegues de Trellis, las migraciones a un nuevo esquema **no vienen incluidas** como parte del deploy. Si trabajas con Acorn (el runtime de Roots con enfoque Laravel), puedes crear y ejecutar **migrations de Laravel** para tus sitios WordPress y encajarlas dentro del proceso de despliegue para tener un flujo más controlado. Aun así, conviene diseñar migraciones compatibles hacia delante/atrás si quieres mantener la opción de rollback con seguridad. #### Ojo con el “downtime lógico” Aunque el cambio de symlink sea instantáneo, una migración destructiva (cambios de columnas, drops, renombres sin compatibilidad) puede romper la release anterior e impedir un rollback limpio. La estrategia de despliegue y la estrategia de migración tienen que ir alineadas. ## Rollback integrado: volver atrás en segundos Una consecuencia directa de tener releases completas e inmutables es que el rollback se vuelve trivial: si el problema está en el nuevo código, basta con repuntar `current` a la release anterior. ``` trellis rollback production ``` Por defecto, Trellis mantiene un número limitado de releases recientes en el servidor (habitualmente cinco). Eso te da una red de seguridad muy práctica: falló algo en producción, vuelves a la release previa sin “deshacer” archivos manualmente. ## Hooks de despliegue: personaliza el pipeline sin hacks En entornos reales, el despliegue casi nunca es solo “subir código”. Trellis expone **hooks** (puntos de extensión) para ejecutar tareas antes o después de pasos concretos del deploy. Por ejemplo: - `deploy_build_before` y `deploy_build_after` para pasos de build personalizados. - `deploy_finalize_before` y `deploy_finalize_after` para tareas justo antes/después de activar la release. - Hooks para cada fase relevante: initialize, update, prepare, build, share y finalize. Esto habilita patrones muy útiles en WordPress moderno: backups de BD antes de publicar, purgas de caché después del cambio, notificaciones internas, o smoke tests contra la release recién desplegada. ## Cómo empezar (sin cambiar tu entorno local) El camino más directo para aprovechar despliegues atómicos con Trellis suele ser: 1. Estructurar el proyecto con [Bedrock](https://roots.io/bedrock/) para ordenar WordPress como aplicación (dependencias con Composer, configuración por entornos, etc.). 2. Instalar y configurar [Trellis](https://roots.io/trellis/) con tus entornos y parámetros de despliegue. 3. Añadir la info de tu repositorio Git en `wordpress_sites.yml`. 4. Ejecutar el despliegue: `trellis deploy production`. El primer despliegue suele ser el más lento porque prepara estructura, instala dependencias y deja todo listo. A partir de ahí, lo importante no es solo la velocidad: es la tranquilidad de publicar sin exponer a tus usuarios a un sitio inconsistente. #### Detalle práctico Según el enfoque descrito por Roots, puedes usar Trellis únicamente para despliegue incluso en servidores que no hayas provisionado con Trellis, y mantener tu stack local preferido. La ganancia está en el método de releases + symlink, no en imponer un único entorno de desarrollo. ## Resumen: qué te llevas si vienes del “FTP a producción” - Un despliegue que no sirve mezclas de versiones: la activación es un cambio atómico de symlink. - Releases inmutables: lo desplegado no se “parchea” en caliente. - Rollback inmediato con un comando, apoyado en el historial de releases. - Hooks para meter tareas reales de operación (cachés, backups, checks) en el pipeline. - La BD sigue siendo tu responsabilidad: planifica migraciones pensando en compatibilidad y reversión. ## Referencias / Fuentes - [Zero Downtime WordPress Deployments with Trellis](https://roots.io/zero-downtime-wordpress-deployments-with-trellis/) - [Deployments | Trellis Documentation](https://roots.io/trellis/docs/deployments/) - [Bedrock](https://roots.io/bedrock/) - [Trellis](https://roots.io/trellis/) - [Creating and running Laravel migrations | Acorn Documentation](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)