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

Automatización de Despliegues WordPress con CI/CD y GitOps

Actualizado el 18 de enero de 2026

Introducción: El caos de los despliegues manuales en WordPress

Gestionar un sitio WordPress en producción implica más que subir archivos por FTP. Cada actualización de plugins, temas o el núcleo puede romper funcionalidades críticas. Los despliegues manuales son propensos a errores humanos, falta de trazabilidad y tiempos de inactividad innecesarios. Aquí es donde entra la automatización de despliegues con CI/CD WordPress y GitOps, un enfoque que convierte el repositorio de código en la única fuente de verdad (single source of truth).

Este artículo te guiará a través de la implementación de pipelines robustos, estrategias de rollback y la integración de GitOps para entornos WordPress. Dejarás atrás los backups manuales y los cambios a ciegas.

¿Qué es CI/CD y GitOps aplicado a WordPress?

CI/CD WordPress: Integración y Entrega Continuas

CI/CD (Continuous Integration / Continuous Deployment) es una práctica de desarrollo que automatiza la construcción, prueba y despliegue de código. En WordPress, esto significa:

  • Integración Continua (CI): Cada cambio en el repositorio (plugins, temas, archivos de configuración) se prueba automáticamente. Por ejemplo, se ejecutan tests de sintaxis PHP, se verifica la compatibilidad de plugins o se analiza la seguridad de dependencias.
  • Entrega/Despliegue Continuo (CD): Una vez que los tests pasan, el código se despliega automáticamente en un entorno de staging o producción. Sin intervención manual.

GitOps: El repositorio como fuente de verdad

GitOps extiende CI/CD usando Git como el centro de control de la infraestructura y las aplicaciones. En lugar de hacer cambios directamente en el servidor, todo se declara en archivos YAML, scripts o configuraciones dentro del repositorio. Un operador (como ArgoCD o Flux) sincroniza el estado real del servidor con el estado deseado en Git.

[INFO] GitOps no solo aplica a Kubernetes. Puedes usarlo con WordPress tradicional usando herramientas como wp-cli y scripts de sincronización.

Beneficios de automatizar despliegues WordPress

  • Reducción de errores humanos: No más olvidos de permisos de archivos o archivos .htaccess incorrectos.
  • Velocidad: Un pipeline bien configurado despliega en minutos, no horas.
  • Trazabilidad: Cada cambio queda registrado en Git con un commit. Sabes quién, cuándo y qué cambió.
  • Rollback instantáneo: Si algo sale mal, revertir a una versión anterior es tan simple como hacer git revert o cambiar el tag en GitOps.
  • Entornos consistentes: Desarrollo, staging y producción se sincronizan automáticamente.

Arquitectura típica de un pipeline CI/CD para WordPress

Antes de escribir código, necesitas definir la arquitectura. Un pipeline típico incluye:

  1. Repositorio Git: Almacena todo el código del tema, plugins personalizados, archivos de configuración (wp-config.php, .htaccess) y scripts de despliegue.
  2. Servidor de CI/CD: GitHub Actions, GitLab CI, Jenkins o Bitbucket Pipelines.
  3. Entornos:
    • Development: Local o en un subdominio.
    • Staging: Réplica exacta de producción para pruebas finales.
    • Production: El sitio en vivo.
  4. Herramientas de despliegue: rsync, wp-cli, ansible, o scripts personalizados.
  5. Base de datos: Gestionada por separado (migraciones con wp-cli db export/import o herramientas como WP Migrate DB Pro).

Ejemplo de estructura de repositorio

/
├── .github/
│   └── workflows/
│       ├── deploy-staging.yml
│       └── deploy-production.yml
├── themes/
│   └── mi-tema-personalizado/
├── plugins/
│   └── mi-plugin/
├── config/
│   ├── wp-config.staging.php
│   └── wp-config.production.php
├── scripts/
│   ├── pre-deploy.sh
│   └── post-deploy.sh
└── README.md

Implementación paso a paso: Pipeline con GitHub Actions

Vamos a construir un pipeline práctico usando GitHub Actions para un sitio WordPress alojado en un VPS con Nginx.

1. Configurar el repositorio y secrets

En GitHub, ve a Settings > Secrets and variables > Actions y añade:

  • SSH_PRIVATE_KEY: Clave privada SSH para conectar al servidor.
  • HOST: IP o dominio del servidor.
  • USER: Usuario SSH.
  • PRODUCTION_PATH: Ruta absoluta a la carpeta de WordPress (ej: /var/www/mi-sitio).
  • STAGING_PATH: Ruta al staging (ej: /var/www/staging.mi-sitio).

2. Crear el workflow de staging

Crea el archivo .github/workflows/deploy-staging.yml:

name: Deploy to Staging

on:
  push:
    branches: [ develop ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'

      - name: Validate composer (if used)
        run: composer validate --strict || true

      - name: Deploy via rsync
        uses: easingthemes/ssh-deploy@v4
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          REMOTE_HOST: ${{ secrets.HOST }}
          REMOTE_USER: ${{ secrets.USER }}
          SOURCE: ./
          TARGET: ${{ secrets.STAGING_PATH }}
          ARGS: '-avz --delete --exclude=".git*" --exclude="node_modules" --exclude=".github"'

      - name: Post-deploy commands
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ${{ secrets.STAGING_PATH }}
            # Copiar config específica de staging
            cp config/wp-config.staging.php wp-config.php
            # Ajustar permisos
            chown -R www-data:www-data .
            find . -type f -exec chmod 644 {} \;
            find . -type d -exec chmod 755 {} \;
            # Limpiar cache (ejemplo con WP Rocket)
            wp cache flush --allow-root
            echo "Staging deploy complete"

[TIP] Usa --delete en rsync con cuidado. Asegúrate de excluir archivos que no deben eliminarse (como wp-config.php si lo generas aparte).

3. Pipeline de producción con aprobación manual

Para producción, el flujo es similar pero con un trigger diferente y un paso de aprobación manual (requiere GitHub Actions environments).

name: Deploy to Production

on:
  push:
    branches: [ main ]

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

  deploy:
    needs: test
    runs-on: ubuntu-latest
    environment: production  # Requiere aprobación manual
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to Production
        uses: easingthemes/ssh-deploy@v4
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          REMOTE_HOST: ${{ secrets.HOST }}
          REMOTE_USER: ${{ secrets.USER }}
          SOURCE: ./
          TARGET: ${{ secrets.PRODUCTION_PATH }}
          ARGS: '-avz --delete --exclude=".git*" --exclude="wp-config.php"'

      - name: Post-deploy production
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ${{ secrets.PRODUCTION_PATH }}
            cp config/wp-config.production.php wp-config.php
            # Backup automático de la BD antes de migrar
            wp db export backups/pre-deploy-$(date +%Y%m%d%H%M%S).sql --allow-root
            # Ejecutar migraciones si las hay
            wp db import migrations/update-1.2.sql --allow-root
            # Limpiar cache de CDN (ejemplo con Cloudflare)
            curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
                 -H "Authorization: Bearer ${{ secrets.CF_TOKEN }}" \
                 -H "Content-Type: application/json" \
                 --data '{"purge_everything":true}'

[WARNING] Nunca subas wp-config.php con contraseñas reales al repositorio. Usa archivos de configuración separados por entorno y secrets de GitHub.

GitOps en WordPress: Sincronización con ArgoCD (ejemplo conceptual)

Aunque GitOps es más común en Kubernetes, puedes emularlo en WordPress con scripts. La idea es tener un operador que revise el repositorio cada cierto tiempo y aplique cambios.

Script básico de GitOps para WordPress

#!/bin/bash
# gitops-sync.sh - Ejecutar como cron cada 5 minutos

REPO_URL="git@github.com:tu-org/wordpress-site.git"
LOCAL_DIR="/tmp/wordpress-gitops"
TARGET_DIR="/var/www/mi-sitio"
BRANCH="main"

# Clonar o actualizar el repo
if [ ! -d "$LOCAL_DIR" ]; then
    git clone --depth 1 --branch $BRANCH $REPO_URL $LOCAL_DIR
else
    cd $LOCAL_DIR && git pull origin $BRANCH
fi

# Sincronizar archivos (excluyendo config y BD)
rsync -avz --delete \
    --exclude="wp-config.php" \
    --exclude=".git" \
    --exclude="backups" \
    $LOCAL_DIR/ $TARGET_DIR/

# Aplicar config si cambió
if [ -f "$LOCAL_DIR/config/wp-config.production.php" ]; then
    cp $LOCAL_DIR/config/wp-config.production.php $TARGET_DIR/wp-config.php
fi

# Notificar si hubo cambios
if [ $? -eq 0 ]; then
    echo "Sincronización completada: $(date)" >> /var/log/gitops.log
fi

Luego configuras un cron:

*/5 * * * * /usr/local/bin/gitops-sync.sh

Estrategias de Rollback en Despliegues Automatizados

La capacidad de rollback es crítica. Aquí tienes tres estrategias:

1. Rollback con Git revert (el más simple)

Si el último commit rompió algo:

git revert HEAD --no-edit
git push origin main

El pipeline se ejecutará de nuevo desplegando el estado anterior.

2. Rollback con tags y versionado

Cada despliegue exitoso crea un tag:

# En el workflow de producción
- name: Tag successful deploy
  run: |
    git config user.name "CI/CD Bot"
    git config user.email "bot@example.com"
    git tag -a "v1.2.3" -m "Deploy production $(date)"
    git push origin "v1.2.3"

Para revertir, solo despliegas un tag anterior:

git checkout tags/v1.2.0
git push origin main --force  # O usa un workflow manual

3. Rollback con snapshots de base de datos

Antes de cada despliegue, guarda un snapshot de la BD:

wp db export /backups/pre-deploy-$(date +%Y%m%d%H%M%S).sql --allow-root

Si necesitas revertir, importas el snapshot y luego reviertes los archivos.

[INFO] Para sitios con mucho tráfico, considera usar blue-green deployment o canary releases. WordPress no es ideal para esto, pero puedes lograrlo con balanceadores de carga y replicación de BD.

Mejores prácticas y consideraciones de seguridad

Gestión de secrets

  • Nunca hardcodees contraseñas de BD o API keys en el repositorio.
  • Usa secrets de GitHub/GitLab y variables de entorno en el servidor.
  • Para wp-config.php, genera el archivo dinámicamente en el pipeline usando variables de entorno.

Pruebas automatizadas

  • PHP Lint: find . -name "*.php" -exec php -l {} \;
  • Seguridad: Ejecuta wp scan (WordPress Security Scanner) o wpscan.
  • Rendimiento: Si tienes staging, corre Lighthouse CI para medir impacto.

Monitoreo post-despliegue

  • Configura alertas en New Relic o Sentry para errores PHP.
  • Usa wp cron event run --due-now para verificar que los cron jobs funcionan tras el despliegue.
  • Monitorea el log de errores: tail -f /var/log/nginx/error.log

Herramientas adicionales para CI/CD WordPress

  • Trellis + Bedrock: Stack moderno de Roots.io para WordPress con gestión de entornos via Ansible y Composer. Ideal para GitOps.
  • WP Pusher: Plugin para desplegar temas y plugins directamente desde repositorios Git.
  • Deployer: Herramienta PHP genérica para despliegues, con recetas para WordPress.
  • Kinsta API / WP Engine API: Si usas hosting gestionado, muchos ofrecen APIs para despliegues automatizados.

Conclusión: El futuro de la gestión de WordPress

Automatizar despliegues con CI/CD WordPress y GitOps transforma la administración de sitios. Pasas de ser un "admin que sube archivos" a un "ingeniero que gestiona código". La inversión inicial en configurar pipelines se amortiza rápidamente en estabilidad, velocidad y tranquilidad.

Comienza con un flujo simple: un repositorio, un workflow de staging y despliegues manuales a producción. Luego añade tests, rollback automático y, finalmente, GitOps puro.

[TIP] No automatices todo de golpe. Empieza por el tema y los plugins personalizados. Deja los plugins del repositorio oficial de WordPress fuera del pipeline y actualízalos manualmente o con un gestor como Composer.

La automatización de despliegues no es un lujo, es una necesidad para cualquier sitio WordPress que aspire a ser profesional, seguro y escalable. ¿A qué esperas para hacer tu primer pipeline?

¿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