El recorrido de un cambio

Así viaja un cambio desde que lo pides hasta que aparece en la web. Claude nunca toca el servidor directamente: su acceso termina en GitHub.

Las piezas y dónde vive cada una

El workflow de GitHub Actions

Este es el archivo completo. Se dispara solo cuando cambia el tema o los scripts de ops/, y también se puede lanzar a mano desde la pestaña Actions. Los valores sensibles nunca aparecen en el archivo: se leen de los secrets.

name: Deploy theme to VPS

on:
  push:
    branches: [main]
    paths:
      - 'themes/mi-tema-hijo/**'
      - 'ops/**'
  workflow_dispatch:

concurrency:
  group: deploy-vps
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - name: Configurar SSH
        run: |
          install -m 700 -d ~/.ssh
          printf '%s\n' "${{ secrets.VPS_SSH_KEY }}" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          printf '%s\n' "${{ secrets.VPS_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

      - name: Desplegar en el VPS
        run: |
          ssh -i ~/.ssh/deploy_key -p "${{ secrets.VPS_PORT }}" \
              -o StrictHostKeyChecking=yes -o BatchMode=yes \
              deploy-github@"${{ secrets.VPS_HOST }}" deploy

      - name: Verificar que el sitio responde
        run: |
          code=$(curl -s -o /dev/null -w '%{http_code}' https://tusitio.com/blog/)
          test "$code" = "200"

concurrency evita que dos despliegues se pisen, StrictHostKeyChecking=yes impide conectarse a un servidor falso y el último paso hace que el job falle si la web deja de responder.

Darle a una máquina la llave de tu servidor

Automatizar un despliegue significa que un sistema externo —GitHub— puede entrar a tu servidor sin que estés mirando. La pregunta correcta no es «¿funciona?», sino «¿qué es lo peor que puede pasar si esa llave se filtra?». Todo el diseño gira alrededor de que la respuesta sea «casi nada».

La idea se llama principio de mínimo privilegio: cada pieza recibe exactamente el permiso que necesita para su tarea, y ni uno más.

Ocho capas entre GitHub y tu servidor

1. Secrets cifradosLa llave privada vive cifrada en GitHub. No aparece en el código ni en los logs.
2. Huella del servidor verificadaGitHub solo se conecta si el servidor presenta la huella registrada (known_hosts). Si alguien suplanta el servidor, la conexión se corta.
3. Usuario dedicado sin contraseñaGitHub no entra como root ni como tu usuario: entra como deploy-github, que tiene la contraseña bloqueada y solo acepta esa llave.
4. Llave con restrictSin terminal, sin túneles, sin reenvío de puertos. Aunque la llave se filtre, no sirve para abrir una sesión.
5. Comando forzadoLo que sea que pida quien se conecte, el servidor ejecuta siempre lo mismo: el script de despliegue. Nada más.
6. sudo para un solo comando, sin argumentosEl usuario de despliegue puede elevar permisos únicamente para ese script y sin pasarle parámetros.
7. Script de root fuera del repositorioQuien pueda escribir en GitHub no puede cambiar lo que corre como root. Ese script se instala a mano en el servidor.
8. Migraciones como www-dataLos cambios de base de datos corren con el mismo usuario que ya usa WordPress, nunca como root.

El error de diseño más común

La tentación es poner el script de despliegue dentro del repositorio y ejecutarlo como root. Funciona, pero tiene un problema serio: cualquiera con permiso de escritura en el repo —incluido alguien que robe un token de GitHub— puede modificar ese script y en el siguiente despliegue ejecutar lo que quiera como root. Escribir en el repo equivale a ser root en el servidor.

Además, si tu servidor tiene el acceso de root por SSH deshabilitado (PermitRootLogin no, como debería), ese diseño ni siquiera funciona. El diseño correcto es un usuario dedicado, un único comando con sudo y el script de root viviendo fuera del repo. Así, lo peor que puede hacer alguien con acceso al repo es lo mismo que ya podría hacer el código PHP del tema: actuar como www-data.

El código no es lo único que cambia

Desplegar archivos es la mitad del trabajo. En WordPress, muchos cambios viven en la base de datos: categorías, extractos, opciones, menús. Si esos cambios se hacen a mano en el panel, se rompe la idea de tener todo automatizado y registrado.

La solución viene del desarrollo con frameworks como Laravel: migraciones. Cada cambio de base de datos es un script numerado en ops/migrations/, escrito con WP-CLI. El script de despliegue ejecuta cada migración una sola vez y guarda el registro de las aplicadas en el servidor, fuera de la web.

Migración 001: categorías del blog

En vez de entrar al panel a renombrar, crear y reasignar categorías, el cambio quedó en un archivo. Es idempotente: si se ejecutara dos veces, el resultado sería el mismo.

#!/usr/bin/env bash
# 001 — Categorías oficiales del blog. Idempotente.
set -euo pipefail

ensure_cat() {   # ensure_cat <slug> <Nombre> [<categoría antigua a renombrar>]
  local slug=$1 name=$2 legacy=${3:-} id
  id=$(wp term list category --slug="$slug" --field=term_id)
  if [ -z "$id" ] && [ -n "$legacy" ]; then
    id=$(wp term list category --name="$legacy" --field=term_id)
  fi
  if [ -n "$id" ]; then
    wp term update category "$id" --name="$name" --slug="$slug"
  else
    wp term create category "$name" --slug="$slug"
  fi
}

ensure_cat sistemas   Sistemas   "Gestion de Servicios"
ensure_cat hardware   Hardware   "Computadoras"
ensure_cat servidores Servidores
ensure_cat software   Software

wp post term set 6262 category servidores --by=slug
wp post update 6262 --post_excerpt="Serie en 2 partes con video real del proceso completo..."

Corregir también es más rápido

Con este flujo, un error deja de ser un problema de horas. Ejemplo real: al probar un filtro del blog, una categoría con un solo artículo mostraba la tarjeta estirada a todo el ancho. Basta con mandarle la captura a Claude: identifica la causa (la grilla usaba auto-fit), la cambia a auto-fill, hace el push y GitHub lo despliega. Recargas la página y está corregido. Lo mismo con contenido: una segunda migración puede reescribir extractos sin entrar al panel.

Glosario

CI/CD

Integración continua / despliegue continuo. Prácticas para que los cambios de código se prueben y lleguen a producción de forma automática.

Pipeline

La secuencia de pasos automáticos por la que pasa un cambio desde el repositorio hasta el servidor.

GitHub Actions

El servicio de automatización de GitHub. Ejecuta tareas en máquinas temporales cuando ocurre un evento, como un push.

Workflow

Archivo YAML en .github/workflows/ que define cuándo y cómo corre una automatización.

Runner

La máquina temporal de GitHub que ejecuta el workflow y se destruye al terminar.

Secret

Valor cifrado guardado en la configuración del repositorio. El workflow lo usa, pero nadie puede volver a leerlo.

Push

Enviar commits del equipo local al repositorio remoto en GitHub.

Fast-forward (--ff-only)

Actualizar solo si no hay cambios en conflicto. Si el servidor tuviera cambios propios, el pull se detiene en vez de mezclar.

SSH

Protocolo cifrado para conectarse a un servidor remoto.

Llave ed25519

Tipo moderno de llave SSH: corta, rápida y segura. La privada se guarda en secreto, la pública se autoriza en el servidor.

known_hosts

Lista de huellas de servidores conocidos. Evita conectarse a un servidor que se hace pasar por el tuyo.

Comando forzado (command=)

Opción de authorized_keys que obliga a una llave a ejecutar siempre el mismo comando, sin importar lo que pida.

restrict

Opción de authorized_keys que quita terminal, túneles y reenvíos a una llave.

sudoers

Configuración que define qué usuario puede ejecutar qué comando con permisos elevados.

Mínimo privilegio

Principio de seguridad: cada pieza recibe solo los permisos que necesita para su tarea.

www-data

El usuario con el que corren Apache y PHP en Ubuntu. WordPress trabaja con sus permisos.

WP-CLI

La línea de comandos oficial de WordPress: permite gestionar posts, categorías, plugins y ajustes sin entrar al panel.

Migración

Script versionado que aplica un cambio a la base de datos una sola vez.

Idempotente

Una operación que, ejecutada varias veces, deja el mismo resultado que ejecutada una vez.

git revert

Crea un commit nuevo que deshace otro anterior, sin borrar el historial.