🧭 Contexto
Durante la evolución de los pipelines CI/CD, Allure pasó de ser un artefacto obligatorio a convertirse en una herramienta de visualización ejecutiva.
La meta fue conservar trazabilidad y análisis, sin acoplar el éxito del pipeline a su generación.
⚙️ Estrategia
- Mantener la ejecución y parsing separados: los tests generan
results/, y Allure solo se usa para renderizar. - Publicar los reportes en un contenedor liviano o bucket S3, accesible tras cada build.
- Integrar Allure Server como capa visual y no como dependencia lógica del pipeline.
- Reducir tiempo de build eliminando pasos redundantes (gzip, zip, copy).
📈 Beneficios
| Métrica | Antes | Después |
|---|---|---|
| Duración del build | 18–20 min | 12 min (−35%) |
| Fallas por Allure | Frecuentes | 0 |
| Visibilidad de QA | Limitada a técnicos | Extendida a negocio |
💡 Lecciones
- Allure debe ser un visor, no un paso del pipeline.
- Menos acoplamiento = mayor resiliencia.
- Publicar los reportes como artefactos permite mantener historia y auditar resultados.
🧠 Rol: Arquitectura de reporting QA
⚒️ Stack: Playwright, Jenkins, Allure Server, OpenShift