Matando moscas a cañonazos con Claude Code y GitHub Actions

Hay un síntoma claro de que llevas demasiado tiempo trabajando con Claude Code: empiezas a obsesionarte con el workflow perfecto.

No con el código. Con el workflow. Con que el pipeline sea elegante, que los steps estén bien organizados, que el bump de versión detecte automáticamente si el commit es un feat: o un fix:, que el deploy SSH no tenga latencia innecesaria, que la E2E contra producción corra justo después del deploy y no antes...

Y mientras te obsesionas con eso, Claude Code va tan rápido que puedes tener 4-5 PRs al día. Cada PR puede ser un merge a master. Cada merge es un deploy. Cada deploy son ~7 minutos de GitHub Actions.

GitHub te da 2.000 minutos gratuitos al mes.

Haz las cuentas.

El pipeline actual: 7 pasos de obra de ingeniería

Después de muchas iteraciones, el pipeline de este portfolio tiene 7 pasos que se ejecutan automáticamente en cada push a master:

1. Bump versión semántica
   feat: → MINOR  |  fix:/docs:/chore: → PATCH
   Commit automático + tag en el repo

2. Deploy SSH al VPS de producción (OVH)
   git pull en /var/www/portfolio

3. composer install --no-dev + optimize-autoloader

4. cache:clear + cache:warmup + reload php-fpm

5. E2E Playwright contra https://josemoreupeso.es
   continue-on-error: true (no bloquea)

6. Back-merge automático master → develop
   [skip ci] para no dispara otro pipeline

7. Sync al repositorio público
   joseguillermomoreu-gif/portfolio-public

Más los checks obligatorios en cada PR:

PHPUnit → PHPStan level 9 → CS Fixer dry-run → ESLint

Si algo falla en el QA de la PR: merge bloqueado. Si algo falla en el deploy: alerta. Si la E2E falla en producción: continue-on-error, pero queda registrado en el historial de Actions.

Funciona perfecto. Desde que lo tengo así, cada merge a master es un deploy a producción en 7 minutos sin tocar nada.

El problema: Claude Code va demasiado rápido

Trabajar con Claude Code en el ritmo de "implementar feature → crear PR → revisar → mergear" tiene una trampa: es tan fluido que puedes hacer 4-5 features al día.

Cada feature tiene su branch, su PR con QA automático (5 min), su merge, y su deploy (7 min). Eso son 12 minutos de GitHub Actions por feature. Cuatro features al día son 48 minutos.

Y si estás en una semana productiva —añadiendo una página de proyectos, un portfolio técnico con keywords interactivos, artículos nuevos, ajustes de UI, fixes de tests...—, esa semana puede tener muchos más de 4 features al día.

Mis 2.000 minutos gratuitos de GitHub del mes desaparecieron antes de llegar a la v17.

v17: el version dump que me hace llorar

El step que más me gusta del pipeline es el bump de versión semántica. Lee los commits desde el último tag, detecta si hay algún feat: (→ incrementa MINOR) o solo fix:/chore:/docs: (→ incrementa PATCH), y hace el bump automáticamente. Actualiza el archivo VERSION, hace el commit y el tag. Sin intervención manual.

Voy por la v18.0.0 de este portfolio ahora mismo. Cada número es un merge a master, un deploy a producción.

Y cada vez que veo ese step ejecutarse en el historial de GitHub Actions... lo reconozco: lloro un poco por dentro.

El script detecta que hay un feat(portfolio): nueva página /portfolio con keywords interactivos, incrementa MINOR (15 → 16 → 17 → 18), hace el commit chore: bump version to 18.0.0 [skip ci], y el pipeline continúa. Siete minutos después, la versión nueva está en producción. Y en el footer de esta página aparece el número correcto.

Es un detalle pequeño. Pero es el tipo de detalle que separa un proyecto que se cuida de uno que simplemente funciona.

¿Vale la pena matar moscas a cañonazos?

Sí. Sin duda.

¿Necesitas E2E contra producción en cada deploy para un portfolio personal con un solo usuario? No. ¿Necesitas back-merge automático cuando puedes hacerlo en 30 segundos a mano? Tampoco. ¿Necesitas sync a un repositorio público en cada deploy? Difícilmente.

Pero el valor no está en la "necesidad" de tenerlo. El valor está en que funciona como en producción real. Cuando en El Confidencial tengo que defender por qué necesitamos E2E en el pipeline de CI/CD, o por qué el bump de versión debe ser automático, tengo un ejemplo ejecutable donde lo demuestro. Donde puedo decir: "mira, esto es lo que hace, así es como falla cuando hay un problema, así es como te avisa, así es el historial limpio que produce".

El portfolio es un laboratorio. Y en este laboratorio el experimento "pipeline de producción real en un proyecto personal" ha sido un éxito.

Aunque ya no tenga minutos gratuitos.

Aunque vaya por la v18.

Aunque llore viéndolo funcionar.