Automatización de CI/CD para WordPress con GitHub Actions y WP-CLI

El desarrollo moderno de sitios web exige velocidad, consistencia y fiabilidad. Para los administradores y desarrolladores de WordPress, gestionar el flujo de trabajo entre el entorno local, el de staging y el de producción puede convertirse en una tarea tediosa y propensa a errores. Aquí es donde entra en juego la automatización de CI/CD (Integración Continua y Despliegue Continuo).

En este artículo, exploraremos cómo construir un pipeline de CI/CD para WordPress utilizando GitHub Actions como orquestador y WP-CLI como herramienta de gestión del CMS. Aprenderás a sincronizar bases de datos, mover archivos, gestionar plugins y garantizar que cada commit en tu repositorio de GitHub se traduzca en un despliegue predecible y seguro.

¿Por qué necesitas CI/CD para WordPress?

Tradicionalmente, los cambios en un sitio WordPress se realizan directamente en producción o mediante plugins de migración manual. Este enfoque tiene varios problemas: sobrescritura accidental de contenido, conflictos de bases de datos, rotura de personalizaciones y falta de control de versiones. Un pipeline de CI/CD WordPress resuelve estos problemas al:

• Estandarizar el proceso: Cada despliegue sigue los mismos pasos, eliminando la variabilidad humana.
• Reducir el downtime: El despliegue se realiza en segundos o minutos, no en horas.
• Mejorar la seguridad: Los secretos (como claves de API o contraseñas de BD) se gestionan mediante variables de entorno, no en el código.
• Facilitar la colaboración: Múltiples desarrolladores pueden trabajar en ramas sin temor a romper el sitio principal.

[INFO] La automatización con WP-CLI es especialmente potente porque permite interactuar con WordPress desde la línea de comandos sin necesidad de interfaz web, lo que es ideal para scripts de CI/CD.

Arquitectura del Pipeline

Antes de escribir código, es crucial entender el flujo. Nuestro pipeline se dividirá en tres fases principales:

1. Integración (CI): Al hacer push a una rama (por ejemplo, develop), se ejecutan tests, se comprueba la sintaxis de PHP y se construye el artefacto.
2. Despliegue (CD): Al hacer push a la rama main (o crear un release), se despliega el código y se ejecutan comandos de WP-CLI para sincronizar la base de datos y los assets.
3. Post-despliegue: Se invalidan cachés, se envían notificaciones y se verifica el estado del sitio.

Requisitos Previos

Para seguir esta guía, necesitarás:

• Un repositorio en GitHub con tu tema y plugins de WordPress (sin el core, que se instalará mediante WP-CLI).
• Un servidor de producción (VPS o hosting con acceso SSH).
• Claves SSH configuradas entre GitHub Actions y tu servidor.
• Conocimientos básicos de YAML y línea de comandos.

Configuración del Entorno: Secretos y Variables

En GitHub, dirígete a Settings > Secrets and variables > Actions. Aquí almacenarás toda la información sensible. Crea los siguientes secretos:

Secreto	Descripción
SSH_PRIVATE_KEY	Clave privada SSH para conectar con el servidor.
SSH_HOST	IP o dominio del servidor de producción.
SSH_USER	Usuario SSH (ej. deploy).
PRODUCTION_DB_NAME	Nombre de la base de datos en producción.
PRODUCTION_DB_USER	Usuario de la BD.
PRODUCTION_DB_PASSWORD	Contraseña de la BD.
PRODUCTION_DB_HOST	Host de la BD (normalmente localhost).
WP_HOME	URL del sitio (ej. https://midominio.com).

[WARNING] Nunca incluyas contraseñas o claves directamente en el archivo YAML. GitHub Actions las inyecta como variables de entorno de forma segura.

Creando el Workflow de GitHub Actions

Los workflows se definen en el directorio .github/workflows/ de tu repositorio. Crearemos un archivo llamado deploy.yml.

1. Integración Continua (CI)

El primer job se ejecuta en cada push a cualquier rama excepto main. Su objetivo es verificar que el código es válido.

name: CI/CD WordPress Pipeline

on:
  push:
    branches: [ develop, main ]
  pull_request:
    branches: [ main ]

jobs:
  ci:
    name: Integración Continua
    runs-on: ubuntu-latest
    steps:
      - name: Checkout del código
        uses: actions/checkout@v4

      - name: Verificar sintaxis PHP
        run: |
          find . -type f -name "*.php" -exec php -l {} \;
          
      - name: Verificar estándares de WordPress (opcional)
        run: |
          # Si usas PHP_CodeSniffer con reglas de WordPress
          # composer install
          # vendor/bin/phpcs --standard=WordPress .

2. Despliegue Continuo (CD)

Este job se activa solo cuando hay un push a main. Aquí es donde ocurre la magia de automatización despliegue.

  cd:
    name: Despliegue Continuo
    if: github.ref == 'refs/heads/main'
    needs: ci  # Solo se ejecuta si CI pasa
    runs-on: ubuntu-latest
    steps:
      - name: Checkout del código
        uses: actions/checkout@v4

      - name: Configurar SSH
        run: |
          mkdir -p ~/.ssh/
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      - name: Sincronizar archivos mediante rsync
        run: |
          rsync -avz --delete \
            --exclude '.git' \
            --exclude '.github' \
            --exclude 'wp-config.php' \
            --exclude 'node_modules' \
            ./ ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:/ruta/a/tu/wordpress/wp-content/themes/mi-tema/
        # Ajusta la ruta de destino según tu estructura de directorios

[TIP] El comando rsync es tu mejor aliado. La opción --delete asegura que los archivos eliminados localmente también se eliminen en producción, manteniendo una copia exacta.

3. Ejecutar WP-CLI en Producción

Una vez que los archivos están en el servidor, necesitamos actualizar la base de datos, limpiar cachés y posiblemente ejecutar migraciones. Aquí es donde WP-CLI brilla.

Añade este paso después de la sincronización de archivos:

      - name: Ejecutar WP-CLI en producción
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "
            cd /ruta/a/tu/wordpress &&
            
            # Actualizar la estructura de la base de datos si es necesario
            wp core update-db --allow-root &&
            
            # Actualizar plugins y temas (opcional, ten cuidado)
            # wp plugin update --all --allow-root --quiet
            
            # Limpiar cachés de WordPress
            wp cache flush --allow-root &&
            
            # Regenerar archivos de traducción si es necesario
            wp language core update --allow-root
          "

4. Gestión de la Base de Datos (Caso Avanzado)

Si tu sitio tiene contenido dinámico que cambia en local (como posts de prueba), es posible que quieras sincronizar la base de datos de producción a local, no al revés. Sin embargo, para despliegues de código, normalmente no tocas la base de datos de producción. Si necesitas aplicar cambios de esquema (por ejemplo, añadir una tabla personalizada), puedes hacerlo con:

      - name: Ejecutar migraciones de base de datos
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "
            cd /ruta/a/tu/wordpress &&
            wp db query < /ruta/a/mi-migracion.sql --allow-root
          "

[WARNING] Manipular la base de datos de producción desde CI/CD es peligroso. Siempre haz un backup antes de ejecutar migraciones automáticas.

Gestión de Múltiples Entornos (Staging y Producción)

Una buena práctica es tener dos workflows separados o usar condicionales para desplegar en staging primero y, tras pruebas, en producción. Puedes modificar el evento on para escuchar etiquetas:

on:
  push:
    tags:
      - 'v*'  # Ejecutar solo cuando se crea un tag como v1.0.0

Luego, dentro del job, extraes la versión y despliegas en producción.

Automatización de Tareas Post-Despliegue

Después de que el código está en vivo, es importante asegurarse de que todo funciona correctamente. Añade estos pasos:

      - name: Verificar estado del sitio
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "
            wp core verify-checksums --allow-root &&
            wp plugin status --allow-root
          "

      - name: Invalidar caché de CDN (opcional)
        run: |
          curl -X POST "https://api.cloudflare.com/client/v4/zones/TU_ZONE_ID/purge_cache" \
            -H "Authorization: Bearer ${{ secrets.CLOUDFLARE_TOKEN }}" \
            -H "Content-Type: application/json" \
            --data '{"purge_everything":true}'

Ejemplo Completo del Workflow

Aquí tienes un workflow completo que une todas las piezas:

name: CI/CD WordPress

on:
  push:
    branches: [ develop, main ]
  pull_request:
    branches: [ main ]

jobs:
  ci:
    name: CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validar PHP
        run: find . -name "*.php" -not -path "./vendor/*" -exec php -l {} \;

  cd:
    name: CD
    if: github.ref == 'refs/heads/main' && success()
    needs: ci
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configurar SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts
      - name: Sincronizar tema
        run: |
          rsync -avz --delete --exclude='.git' --exclude='node_modules' \
            ./ wp@${{ secrets.SSH_HOST }}:/var/www/html/wp-content/themes/mi-tema/
      - name: Ejecutar WP-CLI
        run: |
          ssh wp@${{ secrets.SSH_HOST }} "
            cd /var/www/html &&
            wp core update-db --allow-root &&
            wp cache flush --allow-root
          "
      - name: Healthcheck
        run: curl -I ${{ secrets.WP_HOME }}

Buenas Prácticas y Consejos

• Usa ramas protegidas: En GitHub, protege la rama main para que los merges requieran revisión y los checks de CI pasen.
• Prueba en staging: Crea un job que despliegue en un servidor de staging antes de tocar producción. Puedes hacerlo con una rama staging.
• No incluyas wp-config.php: Este archivo es específico del servidor. Genera uno por entorno usando variables de entorno.
• Monitorea los logs: GitHub Actions proporciona logs detallados. Si un paso falla, revisa el output de rsync o wp.
• Backups automáticos: Antes de cualquier despliegue, programa un backup de la base de datos:

      - name: Backup de BD antes del despliegue
        run: |
          ssh wp@${{ secrets.SSH_HOST }} "
            wp db export /tmp/backup-$(date +%Y%m%d).sql --allow-root
          "

Conclusión

Implementar un pipeline de CI/CD WordPress con GitHub Actions y WP-CLI transforma la forma en que gestionas tu sitio. Ya no es necesario entrar a FTP o al panel de administración para actualizar un archivo; todo se hace mediante commits y merges controlados. La combinación de rsync para archivos y wp-cli para la lógica de WordPress te da un control total y repetible sobre el proceso.

El resultado es un flujo de trabajo profesional, auditable y escalable. Ya sea que administres un solo blog o una red multisitio, esta automatización te ahorrará horas de trabajo y reducirá drásticamente los errores humanos.

[INFO] Si quieres ir un paso más allá, puedes integrar herramientas como Composer para gestionar dependencias de PHP o npm para assets frontend. El límite es tu imaginación y las necesidades de tu proyecto.

Ahora, ve a tu repositorio, configura los secretos y lanza tu primer commit. La automatización te espera.