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/

/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.

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

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 para ordenar WordPress como aplicación (dependencias con Composer, configuración por entornos, etc.).
2. Instalar y configurar 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.

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.