⚡ Workflow en paralelo

Hasta ahora hemos ejecutado todas las tareas de integración continua dentro de un único job.

Aunque este enfoque funciona, tiene una limitación importante:

Todas las tareas se ejecutan de forma secuencial.

Cuando el proyecto crece, esto puede provocar tiempos de espera innecesarios durante la validación del código.

En esta clase veremos cómo dividir nuestro workflow en varios jobs independientes para que GitHub Actions pueda ejecutarlos en paralelo.

🚀 Separando responsabilidades

En lugar de tener un único job que realice todas las comprobaciones, podemos dividir el proceso en varias tareas independientes.

Por ejemplo:

🎨 Frontend Lint

Encargado únicamente de:

Hacer checkout del código
Configurar Node.js y PNPM
Instalar dependencias
Ejecutar el linter del frontend

🖥️ Backend Lint

Encargado de:

Hacer checkout del código
Configurar Node.js y PNPM
Instalar dependencias
Ejecutar el linter del backend

🧪 Frontend Test

Responsable de:

Preparar el entorno
Instalar dependencias
Ejecutar los tests del frontend

🔧 Backend Test

Responsable de:

Preparar el entorno
Instalar dependencias
Ejecutar los tests del backend

De esta forma cada job tiene una única responsabilidad bien definida.

🔄 La ventaja del paralelismo

Una vez separados los jobs, GitHub Actions puede ejecutarlos simultáneamente.

En lugar de tener una ejecución como esta:

Frontend Lint
↓
Backend Lint
↓
Frontend Test
↓
Backend Test

Obtendremos algo parecido a:

Frontend Lint     ─┐
Backend Lint      ├─ Ejecutándose al mismo tiempo
Frontend Test     ┤
Backend Test      ─┘

Esto permite reducir significativamente el tiempo total de ejecución.

📈 Menos tiempo de espera

Puede parecer una mejora pequeña en proyectos de ejemplo.

Sin embargo, en aplicaciones grandes la diferencia puede ser enorme.

Cuando los procesos de linting y testing consumen varios minutos, ejecutarlos en paralelo permite:

Detectar errores antes
Reducir tiempos de espera
Obtener feedback más rápido
Mejorar la productividad del equipo

😬 El problema de duplicar código

Separar jobs tiene una desventaja evidente.

Cada uno necesita repetir pasos como:

Checkout del repositorio
Configuración de Node.js
Instalación de PNPM
Instalación de dependencias

Esto provoca mucha duplicación dentro del workflow.

Algo parecido a:

- Checkout
- Setup Node
- Setup PNPM
- Install dependencies

repetido una y otra vez en cada job.

A medida que el workflow crece, mantener este código se vuelve incómodo.

🧩 Creando una acción compuesta

Para evitar duplicaciones podemos crear una acción reutilizable propia.

GitHub Actions permite definir acciones personalizadas dentro del propio repositorio.

Por ejemplo:

.github/
├── workflows/
└── actions/
    └── setup-pnpm/
        └── action.yml

Esta acción puede encargarse de:

Configurar Node.js
Configurar PNPM
Instalar dependencias
Aplicar caché
Centralizar la configuración común

⚙️ Parámetros configurables

Las acciones compuestas también pueden recibir inputs.

Por ejemplo:

Versión de Node.js
Versión de PNPM

De esta forma la acción se vuelve mucho más flexible y reutilizable.

inputs:
  node-version:
  pnpm-version:

Además, podemos establecer valores por defecto para simplificar su uso.

♻️ Reutilizando la acción

Una vez creada la acción compuesta, cada job puede utilizarla mediante:

uses: ./.github/actions/setup-pnpm

Así eliminamos gran parte de la configuración repetida.

Los workflows quedan mucho más limpios y fáciles de mantener.

⚠️ Errores habituales al crear acciones compuestas

Durante la implementación es frecuente encontrarse con errores.

Algunos de los más comunes son:

No encontrar la acción

Cannot find action.yml

Normalmente ocurre por:

Ruta incorrecta
Nombre incorrecto del directorio
Estructura incorrecta de la acción

Eliminar el checkout por error

Un error muy habitual es intentar mover el checkout dentro de la acción reutilizable.

El problema es que:

Sin checkout, GitHub no descarga el repositorio.

Y si el repositorio no está descargado:

GitHub no puede encontrar la acción local.

Por eso el checkout debe ejecutarse antes de utilizar una acción definida dentro del propio proyecto.

Problemas con caché y PNPM

Otro error frecuente aparece al configurar el caché.

Si Node.js intenta utilizar PNPM para la caché antes de que PNPM esté instalado, la ejecución fallará.

El orden correcto de configuración es importante.

🛠️ Iterar hasta que todo funcione

Trabajar con GitHub Actions implica cometer errores y corregirlos continuamente.

Es completamente normal ver varias ejecuciones fallidas antes de conseguir una versión estable.

Durante el desarrollo es habitual:

Ejecutar workflows
Revisar logs
Corregir errores
Volver a ejecutar

Hasta obtener finalmente una ejecución correcta.

🎯 Resultado final

Al finalizar la refactorización conseguimos:

Jobs independientes
Ejecución en paralelo
Menor tiempo total de integración
Menos código duplicado
Configuración reutilizable mediante acciones compuestas

Además, el workflow resulta mucho más sencillo de mantener a largo plazo.

📌 Ideas clave de esta clase

Quédate con estos conceptos:

Los jobs pueden ejecutarse en paralelo
Separar responsabilidades mejora la organización del workflow
El paralelismo reduce los tiempos de integración continua
Repetir configuración en cada job genera duplicación
Las acciones compuestas permiten reutilizar pasos comunes
Los inputs hacen que las acciones sean configurables
El checkout es necesario para utilizar acciones locales
El orden de configuración de Node.js y PNPM es importante
Los errores durante la creación de workflows son completamente normales

🚀 Lo siguiente

Ahora que los workflows están divididos en jobs paralelos y utilizan acciones reutilizables, el siguiente paso es seguir optimizando la automatización.

A medida que el proyecto crece, estas técnicas permiten construir pipelines más rápidos, más mantenibles y mucho más fáciles de escalar.

💡 Tip: Cuando un workflow empieza a tener mucho código repetido, suele ser una señal clara de que ha llegado el momento de crear una acción compuesta reutilizable.