CI/CD WordPress: Automatización con GitHub Actions y Deployer 2025

Introducción a la Automatización de CI/CD para WordPress

Gestionar un sitio WordPress de forma manual implica tareas repetitivas y propensas a errores: subir archivos por FTP, ejecutar migraciones de base de datos a mano o sincronizar entornos de desarrollo y producción. La automatización de CI/CD (Integración Continua y Despliegue Continuo) resuelve estos problemas al orquestar cada paso del ciclo de vida del desarrollo.

En este artículo, exploraremos cómo implementar un pipeline de CI/CD WordPress utilizando dos herramientas clave: GitHub Actions para la integración y pruebas, y Deployer para el despliegue sin fricciones. Este stack te permitirá aplicar principios DevOps WordPress de forma práctica, reduciendo el tiempo de release y aumentando la fiabilidad de tus sitios.

¿Por qué Automatizar el Despliegue de WordPress?

WordPress, por su naturaleza dinámica (PHP + MySQL), presenta desafíos específicos al automatizar:

Archivos de configuración sensibles: wp-config.php varía por entorno.
Dependencias de plugins y temas: gestionadas con Composer o manualmente.
Base de datos: cambios en el contenido vs. estructura (migraciones).
Plugins de caché y rendimiento: requieren purga tras cada deploy.

Un pipeline de automatización depliegue resuelve estos puntos al centralizar la lógica de build, test y deploy en un solo flujo. Con GitHub Actions y Deployer, obtienes:

Consistencia: cada deploy sigue exactamente los mismos pasos.
Rastreabilidad: cada commit genera un artefacto desplegado.
Rollback rápido: Deployer permite revertir a versiones anteriores en segundos.

Componentes del Pipeline

Antes de escribir código, entendamos las piezas del rompecabezas.

GitHub Actions: El Orquestador

GitHub Actions es la plataforma de CI/CD nativa de GitHub. Permite definir workflows en YAML que se ejecutan ante eventos (push, pull_request, etc.). Para nuestro caso, lo usaremos para:

Instalar dependencias (Composer, Node.js).
Ejecutar linters y tests (PHPCS, PHPUnit).
Compilar assets (CSS/JS con Webpack o Gulp).
Ejecutar Deployer contra el servidor de producción o staging.

Deployer: El Desplegador

Deployer es una herramienta PHP para despliegues automatizados. Se conecta vía SSH y realiza:

Clonado del repositorio en el servidor.
Enlace simbólico a la carpeta current.
Gestión de versiones (releases numerados).
Ejecución de tareas post-deploy (cache, migraciones, permisos).

[INFO] Deployer es ideal para WordPress porque maneja nativamente tareas como deploy:clear_paths para excluir archivos sensibles y deploy:shared_files para compartir wp-config.php entre releases.

Flujo Típico de CI/CD WordPress

El siguiente gráfico muestra el flujo completo desde el commit hasta el servidor:

Desarrollador hace push a la rama main o develop.
GitHub Actions detecta el evento y ejecuta el workflow.
Se instalan dependencias y se ejecutan pruebas.
Si todo pasa, se ejecuta dep deploy vía SSH.
Deployer se conecta al servidor y despliega la nueva versión.
Post-deploy: se limpia caché y se notifica al equipo.

Configuración Paso a Paso

A continuación, la configuración detallada. Asumimos un proyecto WordPress gestionado con Composer (por ejemplo, usando Bedrock de Roots).

1. Preparar el Proyecto WordPress

Tu estructura de directorios debería verse así:

/
├── .github/
│   └── workflows/
│       └── deploy.yml
├── config/
│   ├── application.php
│   └── environments/
│       └── production.php
├── web/
│   ├── wp/
│   └── app/
├── composer.json
├── deploy.php          # Archivo de configuración de Deployer
└── .env.example

[WARNING] Nunca incluyas archivos .env o wp-config.php en el repositorio. Usa deploy:shared_files para sincronizarlos en el servidor.

2. Instalar y Configurar Deployer

Instala Deployer globalmente o como dependencia de desarrollo:

composer require --dev deployer/deployer

Crea el archivo deploy.php en la raíz del proyecto:

<?php
namespace Deployer;

require 'recipe/wordpress.php';

// Configuración del proyecto
set('application', 'Mi Sitio WordPress');
set('repository', 'git@github.com:tu-usuario/tu-repo.git');
set('git_tty', true);
set('keep_releases', 5);

// Servidor de producción
host('produccion')
    ->setHostname('tu-servidor.com')
    ->setPort(22)
    ->setRemoteUser('deployer')
    ->setIdentityFile('~/.ssh/deploy_key')
    ->setDeployPath('/var/www/mi-sitio')
    ->set('branch', 'main');

// Tareas específicas para WordPress
task('deploy:wp_cache_flush', function () {
    run('cd {{release_path}} && wp cache flush');
})->desc('Limpia caché de WordPress');

after('deploy:symlink', 'deploy:wp_cache_flush');

// Archivos compartidos entre releases
set('shared_files', ['.env', 'web/wp-config.php']);
set('shared_dirs', ['web/app/uploads']);

// Archivos a excluir del deploy
set('clear_paths', ['web/wp/wp-content/cache/*']);

[TIP] Deployer incluye una receta específica para WordPress (recipe/wordpress.php) que ya define tareas como deploy:wp, deploy:update_code, etc. Solo necesitas personalizar servidores y tareas post-deploy.

3. Crear el Workflow de GitHub Actions

En .github/workflows/deploy.yml, define el pipeline:

name: Deploy WordPress

on:
  push:
    branches: [ main ]

jobs:
  test-and-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'

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

      - name: Ejecutar linters y tests
        run: |
          vendor/bin/phpcs --standard=WordPress .
          vendor/bin/phpunit

      - name: Compilar assets (si aplica)
        run: |
          npm ci
          npm run build

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

      - name: Desplegar con Deployer
        run: vendor/bin/dep deploy produccion

[INFO] Los secretos SSH_PRIVATE_KEY y otros deben configurarse en GitHub > Settings > Secrets and variables > Actions. Nunca incluyas claves privadas en el repositorio.

4. Configurar Secretos en GitHub

Necesitarás al menos los siguientes secretos:

SSH_PRIVATE_KEY: Clave privada SSH para conectar al servidor.
SERVER_USER (opcional): Si usas usuario dinámico.
ENV_FILE: Contenido del .env de producción (puedes pasarlo como variable de entorno).

Ejemplo de cómo usar un secreto para el archivo .env:

- name: Crear archivo .env
  run: echo "${{ secrets.ENV_FILE }}" > .env

Buenas Prácticas y Consideraciones de Seguridad

Gestión de la Base de Datos

WordPress mezcla contenido (posts, usuarios) con configuración (options). Para CI/CD, lo recomendable es:

No versionar la base de datos completa. Usa migraciones controladas con herramientas como WP-CLI o Bedrock Autoloader.
En Deployer, agrega una tarea que ejecute migraciones:

task('deploy:db_migrate', function () {
    run('cd {{release_path}} && wp db migrate');
});
after('deploy:update_code', 'deploy:db_migrate');

Seguridad en el Servidor

Usa un usuario deployer con permisos mínimos (solo escritura en {{deploy_path}}).
Configura known_hosts estrictamente para evitar ataques man-in-the-middle.
Nunca expongas claves SSH en logs de Actions. Usa add_ssh_key de la acción webfactory/ssh-agent para mayor seguridad.

Rollback Automático

Deployer mantiene releases anteriores. Para hacer rollback manual:

dep rollback produccion

O automatízalo en GitHub Actions si falla el health check post-deploy:

- name: Health check
  run: |
    curl --fail http://tu-sitio.com/wp-json/ || dep rollback produccion

Ejemplo Real: Despliegue de un Tema con Assets Compilados

Supongamos que tu tema usa Webpack para compilar SCSS y JS. El flujo sería:

Push a main.
GitHub Actions instala Node.js, corre npm run build.
Se copian los assets compilados a la carpeta del tema.
Deployer sube todo al servidor.

En el workflow, añade:

- name: Compilar assets del tema
  run: |
    cd web/app/themes/mi-tema
    npm ci
    npm run build

Luego, en deploy.php, asegúrate de que los assets compilados se incluyan (no están en .gitignore):

set('exclude_paths', [
    'node_modules',  // Excluimos node_modules del deploy
    '.git',
    '.env',
]);

[TIP] Para temas grandes, considera usar artefactos de GitHub Actions para compilar los assets una sola vez y reutilizarlos en múltiples deploys.

Monitoreo y Notificaciones

Un pipeline no está completo sin visibilidad. Integra notificaciones en Slack, Discord o correo:

- name: Notificar éxito
  if: success()
  uses: slackapi/slack-github-action@v1.24.0
  with:
    payload: |
      {
        "text": "✅ Deploy exitoso de ${{ github.repository }} a producción"
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

También puedes monitorear el estado de los deploys con herramientas como Better Uptime o Checkly, que ejecutan health checks tras cada release.

Conclusión

La combinación de GitHub Actions y Deployer proporciona un pipeline de CI/CD WordPress robusto, seguro y mantenible. Con esta configuración, cada push a tu rama principal se convierte en un deploy confiable, liberando a tu equipo de tareas manuales y reduciendo el riesgo de errores humanos.

Próximos pasos recomendados:

Implementa tests de integración con Playwright para validar funcionalidades críticas antes del deploy.
Usa entornos de staging automáticos (por ejemplo, con Terraform) para probar cambios en un clon de producción.
Adopta Docker para entornos de desarrollo idénticos a producción.

La automatización no es un lujo, es una necesidad para escalar WordPress con confianza. Empieza hoy con estos pasos y transforma tu flujo de trabajo en un proceso DevOps WordPress de nivel profesional.