Crear un flujo de integración y despliegue continuo en GitHub Actions es el siguiente paso natural después de dominar workflows, eventos, expresiones, variables y secrets. Aquí verás cómo estructurar la fase de testing usando un proyecto open source real, qué jobs necesitas y por qué cada decisión importa para tu pipeline.

¿Qué es un flujo de integración y despliegue continuo en GitHub Actions?

Es la automatización del ciclo de vida de desarrollo de software. Cada vez que subes código nuevo, se ejecutan tests, se compila la aplicación y se despliega en un servidor o servicio cloud sin intervención manual.

¿Qué hace un pipeline CI/CD? Corre tests, compila el proyecto en un formato distribuible (como una imagen Docker) y despliega el resultado en servicios cloud como AWS, GCP o Azure. También recopila métricas de uso para mejorar la aplicación de forma continua.

El flujo se divide en dos grandes fases:

• Integración continua: testear y compilar tu código.
• Despliegue continuo: subir el artefacto compilado a un servidor accesible para tus usuarios.

¿Por qué usar Juice Shop de OWASP como proyecto base?

Juice Shop es un e-commerce mantenido por OWASP, una organización internacional enfocada en la seguridad de Internet [01:54]. Es una aplicación con stack moderno (Angular en el front-end y Node en el back-end) llena de vulnerabilidades a propósito, pensada para que las personas aprendan a identificarlas y evitarlas en sus propios proyectos.

Lo elegí porque cumple con tres condiciones clave para un pipeline robusto:

• Tiene una batería amplia de tests automatizables.
• Se puede compilar en una imagen Docker lista para desplegar.
• Esa imagen se puede subir a cualquier servicio cloud.

Para seguir esta práctica, haz un fork del repositorio a tu cuenta personal. Así puedes modificar los workflows libremente sin necesidad de permisos de maintainer.

¿Cómo se estructura el workflow de tests en CI?

El flujo de integración lo dividí en dos workflows: uno para tests y otro para compilación. El de tests, llamado flujo_ci_test, se dispara con dos eventos: un push a la rama master o un pull request sobre master [05:34].

En la parte superior se configura una variable de entorno con la versión de la CLI de Angular, porque varios jobs y steps la necesitan para correr los tests correctamente.

¿Qué hace el job de lint?

Un linter es una herramienta que mantiene un estilo consistente en los archivos de código: indentación, nombres de variables (camelCase, snake_case), posición de corchetes, espacios. Cada lenguaje y cada equipo define sus propias reglas.

Los pasos del job lint son:

• Checkout del repositorio.
• Configuración de Node 18.
• Instalación de la CLI de Angular usando la variable de entorno.
• npm install para instalar dependencias.
• npm run lint con distintas configuraciones para validar todos los contextos donde corre el proyecto.

¿Por qué usar el SHA del commit en vez de @v3 en un action? Porque si el maintainer del action sube un commit con errores y mueve la etiqueta v3, tu workflow se rompe. Fijar el SHA te asegura usar exactamente la versión que ya validaste como funcional.

¿Cómo funcionan los jobs Test y Test API?

El job Test corre las pruebas unitarias. Después del checkout, configuración de Node, instalación de la CLI de Angular y dependencias, usa el action Retry de Nick Invision (versión 2.8.3) para ejecutar npm test [11:24]. Este action reintenta el comando hasta tres veces si falla, lo cual es útil para tests con fallos intermitentes.

Una vez corren los tests, se genera un reporte de coverage, que mide qué porcentaje del código está cubierto por al menos un test unitario. Esos reportes se copian al root y se suben con el action Upload Artifact de GitHub.

¿Para qué sirve Upload Artifact? Cada job corre en un runner distinto, así que no comparten archivos por defecto. Upload Artifact guarda archivos para que otro job los recupere con Download Artifact más adelante.

El job Test API hace lo mismo pero para tests de integración, ejecutando npm run frisbee, que también está definido en el package.json.

¿Cómo se conectan los jobs con la etiqueta needs?

La etiqueta needs indica que un job solo puede iniciar cuando otros hayan terminado de forma exitosa. En este pipeline, el job que analiza el coverage usa needs para esperar a Test y Test API, porque depende de los reportes que esos jobs subieron como artifacts.

Este job también incluye un condicional if que verifica si la ejecución viene del repositorio original y de un evento push. La razón es que usa Code Climate, una herramienta configurada con credenciales específicas de OWASP a las que un fork no tiene acceso.

¿Qué tipos de tests adicionales corren en el pipeline?

El workflow incluye varias capas de validación:

• Tests personalizados que validan la app en distintos contextos de configuración.
• Tests end-to-end con Cypress, que prueban la aplicación en distintos navegadores y sistemas operativos.
• Tests de humo, que ejecutan comandos predefinidos por los maintainers mediante el script run package CI.
• Test Docker, que corre los tests de humo dentro de la imagen Docker que se compilará en la siguiente fase.

Cada uno de estos jobs sigue un patrón similar: checkout, configuración de Node, instalación de dependencias y ejecución del comando específico. La diferencia está en qué valida cada uno y bajo qué condiciones se activa.

Con esta arquitectura ya tienes la fase de testing del CI cubierta para Juice Shop. ¿Qué tipo de tests vas a automatizar primero en tu propio proyecto? Cuéntalo en los comentarios.