Implementación de despliegues con tiempo de inactividad cero en Cloudways

Puntos clave

• El despliegue sin tiempo de inactividad mantiene tu sitio disponible para los usuarios mientras se lanzan las actualizaciones en segundo plano.
• Cloudways permite despliegues sin tiempo de inactividad mediante entornos de ensayo, flujos de trabajo basados en Git y conmutación atómica de versiones.
• Separar el código de la aplicación de los datos garantiza que las implantaciones nunca sobrescriban las cargas, la configuración o el contenido de la base de datos.
• Las versiones combinadas con un enlace simbólico activo permiten cambiar de versión al instante y realizar reversiones fiables.

Imagina que introduces una actualización rutinaria en tu sitio web activo y, durante unos minutos, los usuarios empiezan a ver errores 500, páginas rotas o contenido a medio cargar. Los compradores abandonan sus carritos, los usuarios registrados pierden sus sesiones y los motores de búsqueda rastrean las páginas de error en lugar de tu contenido real. Incluso una interrupción breve puede significar pérdida de ingresos, usuarios frustrados y daños a largo plazo en el SEO. Este es el tipo de interrupción que puede convertir una simple actualización en un verdadero problema empresarial.

El despliegue sin tiempo de inactividad es un enfoque que permite lanzar actualizaciones de las aplicaciones mientras el sitio sigue disponible para los usuarios, un principio que también soporta SafeUpdates en Cloudways. En lugar de sobrescribir archivos activos o reiniciar servicios a media petición, se prepara una nueva versión por separado y se pasa a producción al instante.

Esta guía describe un enfoque listo para producción para implementar despliegues sin tiempo de inactividad en Cloudways utilizando la puesta en escena, la automatización basada en Git y los lanzamientos atómicos.

Cómo funcionan los despliegues sin tiempo de inactividad en Cloudways

Los despliegues sin tiempo de inactividad en Cloudways son ideales cuando necesitas desplegar cambios de código como temas de WordPress, plugins, lógica personalizada o incluso actualizaciones del núcleo sin interrumpir el tráfico en directo. En lugar de sobrescribir archivos dentro del directorio de la aplicación en vivo (public_html) durante un despliegue, este enfoque prepara una nueva versión en una carpeta separada y la pasa a producción instantáneamente mediante un enlace simbólico. Los usuarios nunca ven páginas rotas, contenidos que faltan o actualizaciones parcialmente cargadas.

El siguiente diagrama ilustra una estructura de despliegue con tiempo de inactividad cero en Cloudways utilizando una aplicación WordPress como ejemplo.

Tu sitio activo siempre se sirve desde el enlace simbólico actual, que apunta a la versión activa dentro del directorio de versiones. El código nuevo se despliega en una versión separada en segundo plano, mientras que los archivos persistentes como la configuración (wp-config.php) y las cargas viven en el directorio compartido y se comparten en todas las versiones mediante enlaces simbólicos. Cuando un despliegue está listo, el tráfico se cambia instantáneamente actualizando el enlace simbólico actual.

El principio básico es desplegar el código de la aplicación manteniendo los datos intactos. Sólo se despliegan los archivos con seguimiento Git, como temas, plugins y código PHP personalizado. Todos los datos de WordPress, incluyendo entradas, pedidos, usuarios y configuraciones, residen en la base de datos y nunca se tocan durante las implantaciones.

Este enfoque es especialmente útil para los usuarios de Cloudways que desean la automatización de GitHub para actualizaciones frecuentes sin poner el sitio en modo de mantenimiento. Combinando Acciones de GitHub con lanzamientos atómicos, consigues despliegues predecibles y repetibles que los usuarios perciben como instantáneos y eliminan el riesgo de tiempo de inactividad a mitad de despliegue.

Ventajas de la implantación sin tiempo de inactividad

La implantación de un tiempo de inactividad cero es una práctica crítica para las empresas de comercio electrónico. Protege las ventas, la confianza de los usuarios y la experiencia de compra en general.

Para los sitios web y aplicaciones de producción, la implantación sin tiempo de inactividad ofrece ventajas prácticas como:

• Experiencia de usuario ininterrumpida: Los visitantes pueden seguir navegando, comprando o interactuando con tu aplicación mientras las actualizaciones se despliegan en segundo plano. No hay pantallas de mantenimiento, páginas rotas ni sesiones perdidas durante las actualizaciones.
• Mayor fiabilidad de los ingresos: Para las tiendas de comercio electrónico, incluso las interrupciones breves pueden provocar pérdidas de ventas. El despliegue con tiempo de inactividad cero evita fallos en el proceso de pago y pedidos perdidos, manteniendo el sitio totalmente accesible durante las actualizaciones, de modo que los clientes nunca se encuentren con páginas de error o carritos rotos mientras se publica el nuevo código.
• Estabilidad SEO mejorada: Los motores de búsqueda no responden bien a los sitios que devuelven regularmente errores 5xx o se desconectan durante las implementaciones. Mantener una disponibilidad constante ayuda a preservar la salud del rastreo y la estabilidad de la clasificación.
• Menor riesgo de lanzamiento: Las nuevas versiones se preparan y validan antes de salir al mercado. Si algo va mal, volver a la versión anterior es rápido y predecible, sin necesidad de revisiones de emergencia.
• Ciclos de envío más rápidos: Los equipos pueden desplegar actualizaciones más pequeñas con mayor frecuencia, sin tener que programar ventanas de mantenimiento nocturnas o coordinarse en torno a bajadas de tráfico. Esto conduce a una iteración más rápida y a lanzamientos más fiables.

Estrategias de implantación sin tiempo de inactividad

Se suelen utilizar varias estrategias establecidas para conseguir despliegues sin tiempo de inactividad, como los despliegues blue-green, las rolling updates y las canary releases. Aunque algunas de ellas requieren una infraestructura compleja, Cloudways soporta enfoques prácticos que funcionan bien para aplicaciones basadas en PHP.

Estas son las estrategias de despliegue sin tiempo de inactividad más eficaces que puedes utilizar en Cloudways:

Habilitar un entorno de ensayo

Cloudways te permite crear un entorno de prueba con unos pocos clics, lo que facilita la prueba de las actualizaciones antes de que salgan a la luz.

Cómo funciona

• Clona tu aplicación de producción para crear un servidor de ensayo.
• Aplica y prueba todas las actualizaciones, incluidos los cambios de código, las actualizaciones de plugins, los cambios de temas e incluso las migraciones de bases de datos, primero en la fase de montaje.
• Valida el rendimiento, la funcionalidad y la compatibilidad en un entorno seguro.
• Una vez que todo esté confirmado, despliega en producción los cambios probados.

Esto reduce el riesgo de implantaciones rotas y garantiza que las actualizaciones de producción sean predecibles y controladas.

Utilizar el despliegue basado en Git

Cloudways es totalmente compatible con los despliegues basados en Git, lo que facilita el envío de código nuevo desde un repositorio Git, como GitHub o GitLab, al servidor.

Cómo funciona

• Conecta tu aplicación Cloudways a un repositorio Git.
• Empuja las actualizaciones a tu rama principal o de ensayo.
• Activa despliegues automáticamente

Los flujos de trabajo basados en Git proporcionan control de versiones, reversiones sencillas y una pista de auditoría limpia de los cambios. Cuando se combinan con herramientas de automatización como las Acciones de GitHub, se convierten en la base de despliegues sin intervención alguna y de bajo riesgo.

Despliegues atómicos con Symlinks mediante acciones de GitHub

Los despliegues atómicos son una de las formas más fiables de conseguir un tiempo de inactividad cero real en Cloudways.

Cómo funciona

• Cada nueva versión se carga en un directorio distinto (por ejemplo: /releases/20260101-000001).
• Un enlace simbólico llamado actual apunta al directorio de la versión activa.
• Una vez que la nueva versión esté totalmente cargada y preparada, se cambia el enlace simbólico al nuevo directorio.
• El cambio se produce casi instantáneamente, por lo que los usuarios nunca experimentan tiempos de inactividad.

Esto funciona bien en Cloudways porque el servidor sigue sirviendo tráfico mientras se prepara la nueva versión, y cuando se cambia el enlace simbólico ocurre casi instantáneamente, por lo que no hay interrupción visible del servicio. Si algo va mal, volver atrás es igual de sencillo, sólo tienes que volver a apuntar el enlace simbólico a la versión anterior.

Cuando se combina con Acciones de GitHub o herramientas similares de CI/CD, este enfoque permite despliegues totalmente automatizados, sin tiempo de inactividad y con una mínima sobrecarga operativa.

Nota:

• Cloudways también admite despliegues sin tiempo de inactividad mediante herramientas de automatización de terceros, como DeployHQ y Capistrano, que se basan en directorios de lanzamiento y conmutación atómica de enlaces simbólicos.
• Con los despliegues basados en enlaces simbólicos, «tiempo de inactividad cero» no significa un tiempo de actividad del sitio del 100%, ya que un breve reinicio de PHP-FPM puede causar errores momentáneos que duren uno o dos segundos.

Utiliza CDN y caché del lado del servidor

Cloudways es compatible con redes de distribución de contenidos (CDN) mediante la integración con Cloudflare y otros servicios de CDN, y también ofrece almacenamiento en caché del lado del servidor mediante Varnish, Redis y Memcached.

Cómo funciona

• Las CDN siguen sirviendo activos estáticos en caché mientras se despliegan los cambios en el backend. Consulta nuestra guía sobre el almacenamiento en caché de WordPress para saber cómo funciona.
• El almacenamiento en caché del lado del servidor reduce la carga de tu aplicación durante los despliegues.
• Los usuarios pueden seguir recibiendo respuestas en caché aunque se reinicien brevemente los servicios backend.

Esta capa adicional de almacenamiento en caché y distribución añade resistencia, garantizando que tu sitio siga siendo accesible mientras se despliegan nuevas versiones de la aplicación.

Conseguir implantaciones sin tiempo de inactividad en Cloudways

Esta sección describe un flujo de trabajo práctico y listo para producción para implementar despliegues sin tiempo de inactividad en Cloudways utilizando WordPress.

Aquí se utiliza WordPress como implementación de referencia, pero la misma estructura de lanzamiento se aplica a otras aplicaciones basadas en PHP con ajustes específicos del marco.

Requisitos previos

Antes de establecer implantaciones de tiempo de inactividad cero, asegúrate de que las siguientes piezas están en su sitio.

• Una aplicación de WordPress que se ejecuta en Cloudways: Este puede ser tu sitio de producción en vivo. Si estás empezando, puedes configurar una aplicación de WordPress utilizando la prueba gratuita de 3 días de Cloudways, que te permite desplegarla y probarla sin añadir detalles de facturación.
• Un repositorio GitHub para tu código WordPress: Tu repositorio debe contener el tema, los plugins personalizados o cualquier código de WordPress que planees desplegar. Esta será la fuente de la verdad para todas las versiones.

Una vez que estén listos, puedes pasar a crear un entorno de ensayo para realizar pruebas seguras y lanzamientos controlados.

Paso 1: Crear una aplicación de ensayo

El primer paso es crear una copia de prueba de tu aplicación WordPress de producción. Esto te proporciona un entorno seguro para probar los cambios antes de lanzarlos en directo.

• Accede a la Plataforma Cloudways utilizando tus credenciales.
• Navega hasta Aplicaciones y localiza tu aplicación WordPress de producción.
• Haz clic en los puntos verticales y selecciona Clonar aplicación/Crear puesta en escena.

• Elige si quieres clonar la aplicación en el mismo servidor para ahorrar costes o en un servidor distinto si quieres un aislamiento completo.
• Marca Crear como puesta en escena, elige un nombre como tudominio-puesta en escena y confirma la acción.

• Espera a que Cloudways termine de aprovisionar la aplicación de staging. Una vez que aparezca, tendrá una etiqueta Staging y su propia URL de aplicación staging.

En este punto, ahora tienes dos aplicaciones separadas, producción y puesta en escena, cada una con su propia ruta de carpeta de aplicaciones. Puedes probar con seguridad las actualizaciones en el staging sin afectar al tráfico en vivo.

Habilitar el acceso SSH para producción y puesta en escena

En la plataforma Cloudways, navega hasta Aplicaciones y selecciona tu aplicación. En Configuración de la aplicación, activa Acceso SSH Shell.

Repite los mismos pasos para tus aplicaciones de producción y de ensayo.

Paso 2: Configuración del servidor

Se trata de una configuración única que prepara tus aplicaciones de producción y de ensayo para despliegues atómicos sin tiempo de inactividad. En este paso, crearás una estructura de versiones, moverás los archivos persistentes a un directorio compartido y actualizarás tu aplicación para que siempre sirva desde una ruta de versiones estable en lugar de archivos activos.

Sólo tienes que hacerlo una vez para cada aplicación, pero asegúrate de repetirlo tanto para tu aplicación de producción como para la de ensayo, para que se mantengan sincronizadas.

Para empezar, ve a la plataforma Cloudways, navega hasta Servidores y selecciona tu servidor. En Credenciales Maestras, haz clic en Iniciar Terminal SSH.

Ejecuta los siguientes comandos dentro del terminal SSH. Sustituye APP_ID por el nombre de la carpeta de tu aplicación. Puedes encontrarlo en la plataforma Cloudways en Aplicaciones → selecciona tu aplicación → Configuración de la aplicación → General → Carpeta.

# Ir a la raíz de la aplicación
cd /home/master/aplicaciones/APP_ID/public_html
APP_ROOT="/home/master/aplicaciones/APP_ID/public_html"

# 1) Crear estructura
# versiones = versiones de la aplicación con fecha y hora
# compartido = datos persistentes (nunca se sobrescriben)
mkdir -p lanzamientos shared shared/uploads

# 2) Copiar archivos persistentes


# Copia los secretos de configuración y BD en compartidos
cp wp-config-sample.php shared/wp-config.php

# Copia las subidas existentes en compartidas
cp wp-content/uploads/* shared/uploads/ 2>/dev/null || verdadero

# 3) Crea la primera versión a partir del código actual
RELEASE_DIR="releases/$(fecha +'%Y%m%d%H%M%S')"
mkdir "$RELEASE_DIR"

# copia sólo el código, omite las carpetas de despliegue y los datos
rsync -a --exclude='releases' --exclude='shared' ./ "$RELEASE_DIR/"

# 4) Añade enlaces simbólicos dentro de esta versión para que utilice la configuración y las cargas compartidas
ln -sfn "$APP_ROOT/compartido/wp-config.php" "$RELEASE_DIR/wp-config.php" || true
ln -sfn "$APP_ROOT/shared/uploads" "$RELEASE_DIR/wp-content/uploads" || true

# 5) Apunta la corriente a esta primera versión
# Interruptor atómico, Nginx sirve la corriente
ln -sfn "$RELEASE_DIR" actual

  # 6) Recargas
  # Activador suave para ayudar a PHP a recoger la nueva versión tras el cambio de symlink
toca wp-config.php && sleep 2  
# Borrar el directorio de caché de WordPress si lo utiliza un plugin de caché
rm -rf wp-content/cache/* 2>/dev/null || verdadero  

Este script configura una estructura de despliegue de WordPress sin tiempo de inactividad:

• Crea un directorio de versiones para las implantaciones versionadas y un directorio compartido para los datos persistentes (configuración y cargas).
• Mueve la configuración y las subidas a compartido para que nunca se sobrescriban.
• Crea una nueva versión con fecha y hora copiando el código base actual.
• Symlinks la configuración compartida y la carga en la nueva versión.
• Cambia atómicamente el enlace simbólico actual para que apunte a la nueva versión, haciéndolo activo al instante.
• Hace que PHP recoja el cambio y borra la caché si está presente.

Actualizar la raíz del documento en Cloudways

Ahora que tu estructura de publicación está en su lugar, el siguiente paso es decirle a Cloudways qué carpeta debe ser tratada como el sitio activo. A partir de este momento, tu aplicación siempre servirá los archivos desde el enlace simbólico actual en lugar de hacerlo directamente desde public_html.

Repite los pasos siguientes para tus aplicaciones de producción y de ensayo:

1. En la plataforma Cloudways, navega hasta Aplicaciones.
2. Selecciona tu aplicación.
3. Abre la Configuración de la aplicación.
4. Establece el Webroot en: /public_html/current

5. Guarda los cambios y visita la URL de tu aplicación.

Tu sitio de WordPress y el panel de administración de WordPress deberían cargarse exactamente igual que antes, sin errores ni páginas rotas.

Si todo parece correcto, tu aplicación está totalmente preparada para implementaciones sin tiempo de inactividad mediante versiones atómicas.

Paso 3: Prepara tu repositorio de GitHub

Este paso prepara tu repositorio de GitHub para que contenga sólo el código desplegable de WordPress, como temas y plugins personalizados, excluyendo los archivos persistentes y generados por el servidor. El objetivo es asegurarte de que rsync y GitHub Actions copian exactamente lo que espera tu script de despliegue sin tiempo de inactividad, sin sobrescribir datos como cargas o archivos de configuración.

Tu repositorio de GitHub debería reflejar el diseño public_html de Cloudways para los despliegues basados en rsync, pero en la mayoría de los casos te centrarás sólo en el código personalizado.

Directrices de la estructura del repositorio

• Guarda tu tema personalizado en wp-content/themes/your-theme/.
• Mantén los plugins personalizados en wp-content/plugins/.
• Excluye los datos generados por el servidor y los persistentes utilizando .gitignore.
• Los archivos del núcleo de WordPress como wp-admin/ y wp-includes/ son opcionales. Puedes omitirlos si actualizas el núcleo de WordPress a través del panel de administración o Cloudways. Inclúyelos sólo si gestionas los archivos del núcleo manualmente o aplicas parches personalizados.

3.1 Crear el repositorio de GitHub

• Ve a github.com y haz clic en Nuevo repositorio.
• Pon un nombre como wordpress-tiempo-de-desactivacion-cero.

• Elige Privado (recomendado).
• No inicialices .gitignore ya que harás push desde Cloudways.
• Crea el repositorio y copia la URL SSH.

Utilizarás un repositorio con dos ramas, la principal para producción y la de ensayo para las implantaciones de ensayo.

3.2 Empujar el código de la aplicación al repositorio de GitHub

Aquí, inicializarás Git dentro de tu aplicación Cloudways y empujarás el código a GitHub.

Repite el mismo proceso para tus aplicaciones de producción y de ensayo, enviando el código de producción a la rama principal y el código de ensayo a la rama de ensayo.

Inicializar Git en el Servidor Cloudways

Accede mediante SSH a tu aplicación y ejecuta los siguientes comandos.

# Ir a la raíz de la aplicación

cd /home/master/aplicaciones/APP_ID/public_html
git init

Crear y configurar .gitignore

Crea un archivo .gitignore desde la raíz de tu repositorio y añade reglas de ignorar específicas de WordPress para que nunca se rastreen los secretos, las subidas y las carpetas de despliegue.

toca .gitignore

Abre el archivo .gitignore en nano o vi y añade el siguiente contenido.

# Estructura de despliegue
liberaciones/
compartido/
corriente/
# Secretos
wp-config.php
.env
# Datos del usuario
wp-content/uploads/
# Caché
wp-content/cache/
wp-content/breeze-config/
wp-content/object-cache.php
wp-content/cache-avanzado.php
# Git/OS
.git/
Almacén DS
*.log

Guarda el archivo y comprueba que no se están rastreando datos sensibles.

cat .gitignore
estado git

No deberías ver cargas, archivos de configuración ni carpetas de despliegue en el resultado.

Cometer y Empujar a GitHub

Una vez que todo esté limpio, confirma el código y envíalo a tu nuevo repositorio de GitHub.

git add .
git commit -m "Código inicial de WordPress"
git remote add origen [email protected]:YOUR_USERNAME/YOUR_REPO.git

• Sustituye TU_NOMBRE_USUARIO por tu nombre de usuario de GitHub o el nombre de tu organización.
• Sustituye TU_REPO por el nombre del repositorio que has creado antes, por ejemplo wordpress-cero-downtime.

Esto conecta tu aplicación Cloudways a tu repositorio de GitHub para que futuras implementaciones puedan extraer código de él.

Para la aplicación de producción, empuja a la rama principal.

git branch -M principal
git push -u origen main

Para la aplicación de ensayo, envíala a la rama de ensayo.

git branch -M puesta en escena
git push -u origen puesta en escena

En este punto, tanto tu rama de producción como la de ensayo están activas en GitHub y listas para ser utilizadas por los despliegues Git de Cloudways y las Acciones de GitHub.

Paso 4: Configurar un flujo de trabajo de acciones de GitHub para despliegues atómicos

Aquí es donde entra en juego la automatización. Un flujo de trabajo de Acciones de GitHub supervisa las ramas principal y de ensayo y se conecta de forma segura a tu servidor Cloudways a través de SSH para ejecutar el despliegue automáticamente. Todo el proceso está diseñado para cambiar las versiones atómicamente, garantizando que las actualizaciones lleguen a producción sin tiempo de inactividad visible.

El siguiente diagrama muestra cómo se ejecuta este flujo de trabajo de despliegue sin tiempo de inactividad, desde la inserción del código hasta el tráfico en directo.

Este flujo de trabajo muestra cómo se despliegan las actualizaciones de la aplicación sin interrumpir el tráfico en directo. Los cambios en el código se envían a GitHub, lo que desencadena un despliegue automatizado a través de las Acciones de GitHub. Se prepara una nueva versión en segundo plano mientras el sitio en vivo permanece intacto, con la configuración compartida y las cargas reutilizadas de forma segura. Una vez lista, un conmutador atómico de enlaces simbólicos activa instantáneamente la nueva versión, permitiendo que el servidor sirva la versión actualizada inmediatamente para que los usuarios vean la actualización sin tiempo de inactividad ni ventana de mantenimiento.

4.1 Generar un par de claves SSH para las acciones de GitHub

Para permitir que las Acciones de GitHub se conecten de forma segura a tu servidor Cloudways, necesitas un par de claves SSH dedicadas.

Ejecuta el siguiente comando en tu máquina local para generar un par de claves SSH:

ssh-keygen -t rsa -b 4096 -C "github-actions-deploy" -f ~/.ssh/cloudways_deploy_rsa -N ""

Este comando genera dos archivos:

• ~/.ssh/cloudways_deploy_rsa
  La clave privada, que utilizarán las Acciones de GitHub.
• ~/.ssh/cloudways_deploy_rsa.pub
  La clave pública, en la que Cloudways confiará.

Añade la clave pública a Cloudways:

• En la plataforma Cloudways, navega hasta Servidores y selecciona tu servidor.
• Credenciales de Maestro Abierto.
• Haz clic en Claves públicas SSH.

• Añade un nombre de etiqueta.

• Pega el contenido completo de la clave pública generada por este comando:

cat ~/.ssh/cloudways_deploy_rsa.pub

• Haz clic en Enviar.

Añade la clave privada a GitHub:

1. Abre tu repositorio de GitHub.
2. Ve a Configuración → Secretos y variables → Acciones.
3. Haz clic en Nuevo secreto de repositorio.
4. Crea un nuevo secreto llamado SSH_PRIVATE_KEY.
5. Pega el contenido completo de la clave privada generada por este comando:

cat ~/.ssh/cloudways_deploy_rsa

4.2 Añadir los secretos necesarios de las Acciones de GitHub

A continuación, proporciona a GitHub Actions los detalles del entorno que necesita para desplegar tu aplicación en Cloudways.

En tu repositorio de GitHub, ve a Configuración → Secretos y variables → Acciones → Nuevo secreto de repositorio, y añade los siguientes secretos:

Clave secreta	Descripción	Cómo encontrar el valor
CLOUDWAYS_APP_PROD	Nombre de la carpeta de la aplicación de producción	Plataforma Cloudways → Aplicaciones → Selecciona tu aplicación de producción → Configuración de la aplicación → General → Carpeta (Copia este nombre de carpeta)
CLOUDWAYS_HOST_PROD	Dirección IP pública del servidor de producción	Plataforma Cloudways → Servidores → Selecciona el servidor que aloja tu aplicación de producción → Credenciales Maestras → IP Pública (Copia esta IP)
CLOUDWAYS_APP_STAGING	Nombre de la carpeta de la aplicación de staging	Plataforma Cloudways → Aplicaciones → Selecciona tu aplicación de staging → Configuración de la aplicación → General → Carpeta (Copia este nombre de carpeta)
CLOUDWAYS_HOST_STAGING	Dirección IP pública del servidor de staging	Plataforma Cloudways → Servidores → Selecciona el servidor que aloja tu aplicación de staging → Credenciales maestras → IP pública (Copia esta IP)
CLOUDWAYS_USER	Nombre de usuario SSH maestro	Plataforma Cloudways → Servidores → Selecciona tu servidor → Credenciales maestras → Nombre de usuario (Copia este nombre de usuario)
CLOUDWAYS_EMAIL	Tu ID de correo electrónico de acceso a Cloudways	Plataforma Cloudways → ID de correo electrónico de inicio de sesión
CLOUDWAYS_API_KEY	Clave secreta de la API de Cloudways	Plataforma Cloudways → Integración de la cuenta → Copia la clave secreta de la API (Regenérala si es necesario)
CLOUDWAYS_SERVER_ID_PROD	ID numérico de la URL del servidor de producción	Plataforma Cloudways → Servidores → Seleccionar servidor de producción → Copiar ID de URL (https://unified.cloudways.com/server/[ID])
CLOUDWAYS_SERVER_ID_STAGING	ID numérico de la URL del servidor de staging	Plataforma Cloudways → Servidores → Seleccionar servidor de puesta en escena → Copiar ID de URL (https://unified.cloudways.com/server/[ID])
CLOUDWAYS_APP_ID_PROD	ID numérico de la URL de la aplicación de producción	Cloudways Platform → Applications → Select production app → Copia el ID de la URL (https://unified.cloudways.com/apps/[ID])
CLOUDWAYS_APP_ID_STAGING	ID numérico de la URL de la aplicación de ensayo	Cloudways Platform → Applications → Select staging app → Copia el ID de la URL (https://unified.cloudways.com/apps/[ID])

Estos secretos permiten que el flujo de trabajo dirija automáticamente los despliegues al servidor y aplicación correctos en función de la rama que se esté empujando.

4.3 Crear el archivo de flujo de trabajo

En tu repositorio, crea un nuevo archivo llamado deploy.yml. Puedes hacerlo directamente desde la interfaz web de GitHub haciendo clic en Añadir archivo → Crear nuevo archivo. En el campo de nombre de archivo, introduce: .github/workflows/deploy.yml

Esta ruta es necesaria para que GitHub lo reconozca como un flujo de trabajo.

Este flujo de trabajo elige automáticamente producción o puesta en escena basándose en el nombre de la rama:

• git push principal despliega a producción

• git push staging despliega en staging

A alto nivel, el flujo de trabajo hace lo siguiente:

• Despliega la rama principal en producción y la rama de ensayo en ensayo.
• Crea una nueva carpeta releases/<timestamp> utilizando el GitHub Actions runner y rsync.
• Copia el código de la aplicación en la carpeta de la nueva versión.
• Symlinks configuración compartida y carga en la liberación.
• Cambia atómicamente la versión actual a la nueva (la versión anterior sigue disponible para retroceder).
• Reinicia PHP-FPM a través de la API de Cloudways.
• Restablece la propiedad y los permisos de los archivos a través de la API de Cloudways.

Como puedes ver en el GIF, cuando envío código nuevo a GitHub, GitHub Actions despliega automáticamente la actualización en Cloudways, cambia el enlace simbólico a la nueva versión y el sitio activo se actualiza sin tiempo de inactividad.

A continuación se muestra un flujo de trabajo deploy.yml listo para producción que despliega código en Cloudways utilizando lanzamientos atómicos y conmutación sin tiempo de inactividad:

name: Despliegue de WordPress en Cloudways sin tiempo de inactividad
en:
  empuja:
  ramas: [ main, staging]
  flujo_trabajo_despacho:

empleos:
  desplegar:
  se ejecuta en: ubuntu-22.04 # Utiliza ubuntu-22.04 para evitar los estados de espera del corredor que se ven con ubuntu-latest


  env:
  APP_FOLDER: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_APP_PROD || secrets.CLOUDWAYS_APP_STAGING }}
  HOST: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_HOST_PROD || secrets.CLOUDWAYS_HOST_STAGING }}
  USUARIO: ${{ secretos.CLOUDWAYS_USER }}


  pasos:
  # 1) Extrae el código del repositorio en el corredor de GitHub
  - utiliza: actions/checkout@v4


  # 2) Generar una marca de tiempo utilizada como nombre de la carpeta de publicación
  - id: vars
  ejecutar: echo "RELEASE=$(fecha +'%Y%m%d%H%M%S')"  >>  $GITHUB_OUTPUT
  shell: bash

  # 3) Sube el código del repositorio a una nueva versión/<marca de tiempo>  en el servidor
  # Excluye los datos compartidos y en tiempo de ejecución para que nunca sobrescribamos uploads/config
  - nombre: Código Rsync a liberar
  utiliza: burnett01/rsync-deployments@v8
  con:
  interruptores: -az --delete --exclude=releases/* --exclude=shared/* --exclude=current --exclude='wp-content/uploads/*' --exclude=wp-config.php --exclude='.git*' --exclude='.github/*'
  ruta: .
  remote_path: /home/master/aplicaciones/${{env.APP_FOLDER }}/public_html/releases/${{pasos.vars.salidas.RELEASE }}/
  host_remoto: ${{ env.HOST }}
  usuario_remoto: ${{ env.USUARIO }}
  clave_remota: ${{ secretos.SSH_PRIVATE_KEY }}

  # 4) Del lado del servidor: prepara el estado compartido, enlaza los persistentes, y luego cambia atómicamente el actual
  - nombre: Despliegue mediante SSH + conmutador symlink
  usos: appleboy/[email protected]
  con:
  host: ${{ env.HOST }}
  nombre de usuario: ${{ env.USER }}
  puerto: 22
  clave: ${{ secretos.SSH_PRIVATE_KEY }}
  script_stop: true


  guión: |
  set -x # Registro de depuración (desactivar una vez estable)
  RELEASE="${{ pasos.vars.salidas.RELEASE }}"
  APP_ROOT="/home/master/aplicaciones/${{ env.APP_FOLDER }}/public_html"


  cd "$APP_ROOT"


  # Asegúrate de que existen carpetas de despliegue
  mkdir -p lanzamientos shared shared/uploads

  # Asegúrate de que rsync ha creado realmente la carpeta release  
  if [ ! -d "releases/$RELEASE" ]; then
  echo "Falta la carpeta Release: releases/$RELEASE"
  salida 1
  fi

  # Symlink persistentes (Dentro de la liberación, apunta config y subidas a compartidos)
  cd "releases/$RELEASE"
  rm -rf wp-content/uploads
  ln -sfn "$APP_ROOT/compartido/wp-config.php" wp-config.php || true
  ln -sfn "$APP_ROOT/shared/uploads" wp-content/uploads || true

  # Interruptor atómico de tiempo cero
  cd "$APP_ROOT"
  ln -sfn "releases/$RELEASE" actual
  ls -la actual && echo "Cambiado a $RELEASE"
              
  # Activador suave para ayudar a PHP a recoger la nueva versión tras el cambio de symlink
  touch "$APP_ROOT/actual/wp-config.php" && sleep 2
          
  # Vaciar la caché de WordPress después de la instalación si WP-CLI está disponible
  WP_CLI=$(comando -v wp || echo "")
  if [ -n "$WP_CLI" ] && [ -r "$APP_ROOT/current/wp-config.php" ]; then
  si $WP_CLI core está-instalado --allow-root  >/dev/null 2>&1; entonces
  $WP_CLI vaciar caché --allow-root || true
  fi
  fi
            
  # Borrar el directorio de caché de WordPress si lo utiliza un plugin de caché
  rm -rf "$APP_ROOT/actual/wp-content/cache/"* 2>/dev/null || verdadero


  echo "$(readlink actual) [$LIBERACIÓN]"

            
  # 5) Reinicio de PHP-FPM + restablecimiento de permisos de archivos
  - nombre: Reinicio y permisos de la API de Cloudways
  env:
  CLOUDWAYS_EMAIL: ${{ secretos.CLOUDWAYS_EMAIL }}
  CLOUDWAYS_API_KEY: ${{ secretos.CLOUDWAYS_API_KEY }}
  CLOUDWAYS_SERVER_ID: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_SERVER_ID_PROD || secrets.CLOUDWAYS_SERVER_ID_STAGING }}
  CLOUDWAYS_APP_ID: ${{ github.ref == 'refs/heads/main' && secrets.CLOUDWAYS_APP_ID_PROD || secrets.CLOUDWAYS_APP_ID_STAGING }}
           
  Corre: |
  # Obtener token OAuth
  CLOUDWAYS_TOKEN=$(curl -s -X POST \N -$(curl -s -X POST)
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept: application/json' \
  -d "email=${CLOUDWAYS_EMAIL}&api_key=${CLOUDWAYS_API_KEY}" \
  https://api.cloudways.com/api/v1/oauth/access_token
  | jq -r '.access_token')

  # Reinicia PHP-FPM para este servidor
  curl -s -X POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept: application/json' \
  --header "Autorización: Portador ${CLOUDWAYS_TOKEN}" \
  -d "server_id=${CLOUDWAYS_SERVER_ID}&service=php8.1-fpm&state=restart" \
  https://api.cloudways.com/api/v1/service/state

  # Restablece los permisos de tu aplicación de ensayo o producción
  curl -s -X POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept: application/json' \
  --header "Autorización: Portador ${CLOUDWAYS_TOKEN}" \
  -d "server_id=${CLOUDWAYS_SERVER_ID}&app_id=${CLOUDWAYS_APP_ID}&propiedad=usuario_sistema" \
  https://api.cloudways.com/api/v2/app/manage/reset_permissions

  echo "Permisos restablecidos para app_id=${CLOUDWAYS_APP_ID}"
  shell: bash

Nota: Este flujo de trabajo de despliegue se centra estrictamente en el código de la aplicación. Los cambios en la base de datos se gestionan por separado y no forman parte de este proceso de despliegue. La base de datos se gestiona de forma independiente a través de MySQL o MariaDB en Cloudways y no forma parte del sistema de archivos de la aplicación.

Paso 5: Valida el flujo y ponte en marcha

En esta fase, tu canal de despliegue sin tiempo de inactividad está totalmente conectado y listo para su uso real. Antes de poner nada en marcha, es importante validar el flujo completo de extremo a extremo utilizando tu entorno de ensayo. Esta comprobación final garantiza que los despliegues se comportan exactamente como se espera, sin afectar al tráfico real.

5.1 Probar la tubería de despliegue de etapas

Comienza activando un despliegue en la puesta en escena. Empieza con un cambio pequeño y de bajo riesgo, como actualizar un archivo CSS en tu tema o añadir un comentario visible en una plantilla. Esto facilita la confirmación de que la nueva versión se está desplegando realmente.

Confirma y envía el cambio a la rama de preparación.

git checkout staging
git add .
git commit -m "Prueba de despliegue"
git push origen puesta en escena

Una vez completado el push, abre GitHub → Acciones y observa cómo se ejecuta el flujo de trabajo. Un despliegue correcto debería completarse con una marca de verificación verde, confirmando que la automatización se ejecutó sin errores.

A continuación, verifica el lugar de montaje:

• Visita la URL de la aplicación de ensayo
• Confirma que el nuevo cambio es visible
• Asegúrate de que el frontend se carga correctamente
• Comprueba que el administrador de WordPress funciona como se espera
• Comprueba que no aparecen errores durante la carga normal de la página

Para validar completamente la implantación, accede mediante SSH a la aplicación de ensayo y confirma la estructura de lanzamiento:

• Existe una nueva carpeta con fecha y hora dentro del directorio de versiones
• El enlace simbólico actual apunta a la última versión
• Los archivos compartidos, como las subidas y la configuración, están correctamente enlazados simbólicamente

Si todo parece correcto, tu canal de despliegue está funcionando según lo previsto sin tocar el tráfico en directo.

5.2 Promover cambios en la producción

Una vez verificada la puesta en escena, pasar los mismos cambios a producción es intencionadamente sencillo.

Fusiona la rama staging con la main y empuja la actualización.

git checkout principal
git merge puesta en escena
git push origen main

Esto activa el mismo flujo de trabajo de Acciones de GitHub, esta vez utilizando secretos de producción. Entre bastidores:

• Se prepara un nuevo comunicado de producción en segundo plano
• La configuración y las cargas compartidas se reutilizan de forma segura
• El enlace simbólico actual cambia atómicamente

Mientras se ejecuta el despliegue, supervisa el flujo de trabajo en Acciones de GitHub para confirmar que se completa correctamente.

Tras la correcta implantación, verifica el sitio web de producción en vivo:

• Abre la URL de producción
• Confirma que la actualización es visible
• Comprueba la funcionalidad de administración de WordPress
• Revisa los registros en Aplicaciones → Selecciona tu aplicación → Monitorización → Registros

Desde la perspectiva del visitante, nada se desconecta nunca. La actualización simplemente está disponible.

Paso 6: Supervisión y retrocesos instantáneos

El tiempo de inactividad cero no termina una vez finalizado el despliegue. La monitorización continua y la capacidad de recuperación rápida son lo que hacen que este enfoque sea fiable en producción. Cloudways proporciona herramientas integradas que facilitan la validación de los despliegues y la respuesta rápida si algo va mal.

6.1 Monitorizar los despliegues en Cloudways

La supervisión debe integrarse directamente en tu proceso de lanzamiento. Después de cada despliegue, dedica unos instantes a verificar el comportamiento de la aplicación antes de dar por concluida la liberación.

Desde la Plataforma Cloudways:

1. Navegar a Aplicaciones
2. Selecciona tu aplicación
3. Abrir Monitorización → Registros

Revisa los siguientes registros:

• Registros de acceso para conocer las solicitudes web, el estado de las solicitudes, las IP de los visitantes y las páginas visitadas.
• Registros de errores para comprobar los errores y advertencias que indican posibles problemas con los eventos o la configuración de la aplicación.

Convertir la supervisión posterior a la implantación en un paso estándar de tu flujo de trabajo ayuda a detectar los problemas a tiempo y reduce el riesgo de que los usuarios tengan problemas.

6.2 Retroceder instantáneamente (si es necesario)

La planificación del desmantelamiento también debe formar parte del proceso de despliegue, no ser algo que se decida durante un incidente.

Como cada implementación se almacena en su propio directorio de versiones, la reversión en Cloudways es rápida, predecible y segura. Volver a una versión anterior es un simple cambio de enlace simbólico, sin restauración de archivos ni correcciones de emergencia.

Para retroceder:

• Identifica una versión buena conocida anterior en el directorio de versiones
• Apunta el enlace simbólico actual a esa versión
• Borra las cachés de las aplicaciones si es necesario

El tráfico retrocede inmediatamente, restaurando la versión anterior sin tiempo de inactividad. Tratar la reversión como un paso definido del flujo de trabajo garantiza que la recuperación sea tranquila, controlada y fiable cuando surjan problemas.

Buenas prácticas de despliegue sin tiempo de inactividad

Implantar un despliegue con tiempo de inactividad cero no sólo tiene que ver con las herramientas y los flujos de trabajo que utilices. La fiabilidad a largo plazo se consigue siguiendo las mejores prácticas de implantación con tiempo de inactividad cero, que mantienen las implantaciones seguras, predecibles y fáciles de recuperar.

Las siguientes directrices de despliegue con tiempo de inactividad cero funcionan especialmente bien para las aplicaciones alojadas en Cloudways.

Despliega siempre el código separado de los datos

El código de la aplicación debe tratarse como desechable, mientras que los datos deben permanecer persistentes. Mantén los archivos de configuración, las cargas y el contenido generado por el usuario fuera de tus directorios de despliegue y reutilízalos mediante enlaces simbólicos. Esto garantiza que los despliegues nunca sobrescriban datos críticos y hace que las reversiones sean seguras y rápidas.

Utiliza la puesta en escena para cada versión

Un entorno de ensayo es esencial para validar los cambios antes de que lleguen a producción. Prueba siempre primero los despliegues, las actualizaciones de plugins y los cambios de configuración en el entorno de pruebas. En Cloudways, las aplicaciones de ensayo reflejan fielmente las de producción, lo que facilita la detección temprana de problemas y la publicación con confianza.

Automatiza las implantaciones de principio a fin

Los despliegues manuales aumentan el riesgo de error humano. Utiliza flujos de trabajo basados en Git y herramientas de automatización como Acciones de GitHub para estandarizar cómo se libera el código. La automatización garantiza que cada despliegue siga los mismos pasos, reduciendo las incoherencias entre entornos.

Haz que los comunicados sean pequeños y frecuentes

Los cambios más pequeños son más fáciles de probar, revisar y revertir si es necesario. Los lanzamientos frecuentes reducen el impacto de un único despliegue y facilitan la identificación de problemas. Este enfoque también se alinea bien con las estrategias de tiempo de inactividad cero, en las que los cambios se preparan y conmutan atómicamente.

Monitoriza inmediatamente después de cada despliegue

Los momentos posteriores a una implantación son críticos. Revisa los registros de aplicaciones, los registros de errores y las métricas de rendimiento justo después de cada despliegue. Cloudways proporciona acceso integrado a los logs de las aplicaciones, lo que facilita la detección y resolución de problemas antes de que afecten a los usuarios.

Haz que la reversión forme parte del proceso

El despliegue sin tiempo de inactividad está incompleto sin una estrategia clara de reversión. Mantén siempre disponibles las versiones anteriores y sabe exactamente cómo volver atrás si algo va mal. En Cloudways, volver atrás es tan sencillo como volver a apuntar a la versión activa y borrar las cachés.

Documenta tu flujo de trabajo de despliegue

Una documentación clara ayuda a los equipos a desplegar con coherencia y confianza. Documenta cómo funcionan las implantaciones, dónde viven las versiones y cómo se realizan las reversiones. Esto reduce el tiempo de incorporación y garantiza que todos sigan el mismo proceso fiable.

Conclusión

El despliegue sin tiempo de inactividad es ahora un requisito estándar para mantener la disponibilidad durante los lanzamientos de producción. Con Cloudways, no necesitas una infraestructura compleja para conseguirlo. Una combinación bien estructurada de entornos de preparación, flujos de trabajo basados en Git y conmutación atómica de enlaces simbólicos es suficiente para ofrecer actualizaciones fiables y sin interrupciones.

Al separar el código de los datos y automatizar las implementaciones mediante las Acciones de GitHub, creas un proceso de publicación repetible que se amplía a medida que crece tu sitio. Las actualizaciones se vuelven predecibles, las reversiones son instantáneas y los despliegues ya no parecen arriesgados. Tanto si gestionas un sitio WordPress, una tienda de comercio electrónico o una aplicación PHP personalizada, este enfoque te permite enviar cambios con confianza sin interrumpir el tráfico en directo.

Una vez implantado, el despliegue sin tiempo de inactividad se convierte en una parte natural de tu flujo de trabajo, permitiendo que las actualizaciones lleguen a producción mientras el sitio sigue estando totalmente disponible, para que tu equipo pueda centrarse en crear funciones en lugar de gestionar lanzamientos.