🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Automatización del Deployment en WordPress con CI/CD y GitHub Actions

Actualizado el 5 de junio de 2026

Introducción: Por qué necesitas un pipeline CI/CD para WordPress

Mantener un sitio WordPress actualizado, seguro y con despliegues predecibles es un desafío creciente. La práctica común de subir archivos por FTP, modificar archivos en producción o instalar plugins directamente desde el panel de administración introduce riesgos de seguridad, inconsistencias entre entornos y tiempos de inactividad no planificados. Aquí es donde la automatización del deployment con CI/CD WordPress cambia las reglas del juego.

Un pipeline de Integración Continua y Despliegue Continuo (CI/CD) te permite automatizar las pruebas, la construcción y el despliegue de tu sitio WordPress cada vez que realizas un cambio en tu repositorio de Git. Al combinar esto con GitHub Actions WordPress, obtienes una plataforma gratuita, potente y perfectamente integrada con tu flujo de trabajo de desarrollo. En este artículo, exploraremos cómo construir un deployment automático WordPress robusto, incluyendo estrategias para el rollback WordPress y la gestión de pipelines.

Conceptos fundamentales de un pipeline CI/CD para WordPress

Antes de escribir código, es crucial entender los componentes de un pipeline moderno. Un pipeline WordPress típico consta de las siguientes etapas:

  1. Código Fuente (Git): Todo el tema, los plugins personalizados y el contenido (a menudo gestionado con un starter theme como Sage o Underscores) vive en un repositorio Git. El core de WordPress y los plugins del repositorio oficial se gestionan por separado (por ejemplo, con Composer).
  2. Integración Continua (CI): Cada push o pull request activa un workflow. Este workflow ejecuta:
    • Linting de PHP (PHPCS, Psalm).
    • Pruebas unitarias (PHPUnit).
    • Compilación de assets (Webpack, Vite).
    • Escaneo de seguridad básico.
  3. Despliegue Continuo (CD): Si la etapa de CI pasa y el cambio está en la rama principal (por ejemplo, main o staging), se ejecuta el despliegue. Esto implica:
    • Sincronizar archivos (vía RSync, SCP o un script personalizado).
    • Ejecutar migraciones de base de datos (si aplica).
    • Limpiar cachés (CDN, Redis, WordPress transients).

[INFO] No todos los sitios WordPress necesitan un pipeline completo. Si gestionas un blog personal pequeño, un plugin de staging como WP Staging puede ser suficiente. Sin embargo, para agencias, sitios de comercio electrónico o proyectos con múltiples desarrolladores, un pipeline CI/CD es indispensable.

Configuración del repositorio y GitHub Actions

Para empezar, necesitas un repositorio que contenga tu tema y plugins. Vamos a asumir que usas un enfoque moderno con Composer para gestionar las dependencias.

Estructura de directorios recomendada

mi-sitio-wordpress/
├── .github/
│   └── workflows/
│       └── deploy.yml
├── web/
│   ├── app/
│   │   ├── themes/
│   │   │   └── mi-tema-personalizado/
│   │   └── plugins/
│   │       └── mi-plugin-personalizado/
│   ├── wp-config.php
│   └── index.php
├── composer.json
├── composer.lock
└── .gitignore

Creando el Workflow de GitHub Actions

Dentro de .github/workflows/deploy.yml, definiremos nuestro pipeline. Este archivo YAML es el corazón de la automatización.

name: Deploy WordPress

on:
  push:
    branches:
      - main
      - staging

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout del código
        uses: actions/checkout@v4

      - name: Configurar PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          tools: composer, wp-cli

      - name: Instalar dependencias de Composer
        run: composer install --no-dev --optimize-autoloader

      - name: Compilar assets (Node)
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build

      - name: Sincronizar archivos al servidor
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
          DEPLOY_HOST: ${{ secrets.DEPLOY_HOST }}
          DEPLOY_USER: ${{ secrets.DEPLOY_USER }}
          DEPLOY_PATH: ${{ secrets.DEPLOY_PATH }}
        run: |
          echo "$DEPLOY_KEY" > deploy_key
          chmod 600 deploy_key
          rsync -avz --delete --exclude='.git' --exclude='node_modules' \
            -e "ssh -i deploy_key -o StrictHostKeyChecking=no" \
            ./ $DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH

      - name: Limpiar caché de WordPress
        run: |
          ssh -i deploy_key -o StrictHostKeyChecking=no $DEPLOY_USER@$DEPLOY_HOST \
            "cd $DEPLOY_PATH && wp cache flush --allow-root"

[WARNING] Nunca subas tu deploy_key o credenciales al repositorio. Utiliza GitHub Secrets (Settings > Secrets and variables > Actions) para almacenar DEPLOY_KEY, DEPLOY_HOST, DEPLOY_USER y DEPLOY_PATH. La clave SSH debe ser una clave dedicada, con permisos restringidos solo a la carpeta del proyecto.

Estrategias de Rollback: El plan B que necesitas

Uno de los mayores temores al automatizar despliegues es que un error en el código rompa el sitio en producción. Por eso, un buen rollback WordPress no es opcional, es una necesidad. Aquí tienes tres estrategias que puedes implementar en tu pipeline.

1. Rollback por etiquetas o versiones semánticas

En lugar de desplegar directamente desde main, puedes usar tags de Git. Cada tag representa una versión estable. Si algo sale mal, despliegas el tag anterior.

on:
  push:
    tags:
      - 'v*'

En el paso de despliegue, puedes extraer el nombre del tag y mantener un historial de despliegues en el servidor.

2. Mantener versiones anteriores en el servidor (Blue-Green Deployment)

Una técnica más avanzada consiste en mantener dos directorios en el servidor: current y previous. El pipeline despliega en un directorio nuevo (ej. release-20250328), luego cambia un enlace simbólico (current -> release-20250328). Si falla, simplemente apuntas el enlace simbólico de vuelta a previous.

# Dentro del paso de despliegue
# 1. Crear el nuevo release
rsync -avz ... /var/www/releases/release-${{ github.sha }}/

# 2. Actualizar el enlace simbólico
ssh user@host "ln -sfn /var/www/releases/release-${{ github.sha }} /var/www/current"

# 3. (Opcional) Mantener solo los últimos 5 releases
ssh user@host "ls -t /var/www/releases/ | tail -n +6 | xargs -I {} rm -rf /var/www/releases/{}"

3. Rollback con WP-CLI y snapshots de base de datos

Si tu despliegue incluye cambios en la base de datos (plugins que añaden tablas, opciones de tema), necesitas un rollback de BD. Puedes usar WP-CLI para tomar un snapshot antes del despliegue.

- name: Backup de base de datos antes del despliegue
  run: |
    ssh -i deploy_key user@host \
      "cd /var/www/current && wp db export /tmp/backup-pre-deploy.sql --allow-root"

Si el despliegue falla, ejecutas un paso manual o automatizado para importar ese backup y restaurar los archivos anteriores.

Mejores prácticas para pipelines WordPress robustos

Construir un deployment automático WordPress no termina con el primer workflow funcional. Para que sea realmente fiable, sigue estas prácticas.

Gestión de secretos y entornos

  • Variables de entorno: No hardcodees nada. Usa un archivo .env en el servidor (nunca en Git) y configúralo en el paso de despliegue. GitHub Actions puede inyectar variables directamente.
  • Entornos múltiples: Crea workflows separados para staging y production. El pipeline de staging puede ser más permisivo (despliegue automático), mientras que production debería requerir aprobación manual.
# Ejemplo de aprobación manual para producción
environment:
  name: production
  url: https://tusitio.com

Pruebas automatizadas específicas de WordPress

No te limites a linting básico. Integra pruebas que validen el comportamiento de tu tema.

  • PHPStan/Psalm: Análisis estático para detectar errores de tipo.
  • PHPUnit con WP_Mock: Para probar funciones y clases de tu tema sin necesidad de una base de datos.
  • Lighthouse CI: Si tu tema tiene muchos assets, verifica el rendimiento con Lighthouse como parte del pipeline.
- name: Ejecutar PHPStan
  run: vendor/bin/phpstan analyse --level=max web/app/themes/mi-tema

Notificaciones y monitoreo

¿Qué pasa si el despliegue falla? Configura notificaciones en Slack, Discord o por correo.

- name: Notificar éxito o fallo
  if: always()
  uses: slackapi/slack-github-action@v1.24.0
  with:
    payload: |
      {
        "text": "Despliegue a producción ${{ job.status }} para ${{ github.sha }}"
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

[TIP] No confíes ciegamente en rsync --delete. Siempre ten un backup del directorio wp-content/uploads (que normalmente no está en Git) y exclúyelo de la sincronización para no borrar subidas de usuarios.

Ejemplo completo: Pipeline con pruebas, despliegue y rollback

A continuación, un ejemplo unificado que integra todo lo anterior. Este pipeline se activa al hacer push a main, ejecuta pruebas, despliega usando el método Blue-Green y notifica el resultado.

name: CI/CD Completo WordPress

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          tools: composer, wp-cli
      - run: composer install
      - run: vendor/bin/phpcs --standard=WordPress web/app/themes/mi-tema
      - run: vendor/bin/phpunit

  deploy:
    needs: test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          tools: composer
      - run: composer install --no-dev --optimize-autoloader

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm run build

      - name: Backup DB y archivos
        run: |
          ssh -i ${{ secrets.DEPLOY_KEY }} ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} \
            "cd ${{ secrets.DEPLOY_PATH }}/current && wp db export /tmp/backup-${{ github.sha }}.sql --allow-root"

      - name: Desplegar nueva versión
        run: |
          RELEASE_DIR="release-${{ github.sha }}"
          ssh ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} "mkdir -p ${{ secrets.DEPLOY_PATH }}/releases/$RELEASE_DIR"
          rsync -avz --delete --exclude='.git' --exclude='node_modules' \
            -e "ssh -i ${{ secrets.DEPLOY_KEY }} -o StrictHostKeyChecking=no" \
            ./ ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }}:${{ secrets.DEPLOY_PATH }}/releases/$RELEASE_DIR
          ssh ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} \
            "ln -sfn ${{ secrets.DEPLOY_PATH }}/releases/$RELEASE_DIR ${{ secrets.DEPLOY_PATH }}/current"

      - name: Limpiar releases antiguos
        run: |
          ssh ${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }} \
            "ls -t ${{ secrets.DEPLOY_PATH }}/releases/ | tail -n +4 | xargs -I {} rm -rf ${{ secrets.DEPLOY_PATH }}/releases/{}"

      - name: Notificar éxito
        if: success()
        run: echo "Despliegue exitoso a producción"

Conclusión: El futuro del deployment en WordPress

La automatización del Deployment en WordPress con CI/CD y GitHub Actions transforma la forma en que gestionas tus sitios. Ya no dependes de procesos manuales propensos a errores; tienes un sistema predecible, auditable y rápido. Implementar pipelines WordPress te permite centrarte en escribir mejor código, sabiendo que el despliegue es seguro y que, si algo falla, el rollback WordPress está a solo un commit de distancia.

Empieza poco a poco: primero automatiza el despliegue de tu tema en un entorno de staging. Luego añade pruebas. Finalmente, implementa la estrategia de rollback. Con el tiempo, tu deployment automático WordPress será tan fiable como el propio CMS.

[INFO] Para profundizar, revisa la documentación oficial de GitHub Actions para WordPress y explora acciones comunitarias como rtCamp/action-wordpress-deploy que simplifican aún más el proceso.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel