Sankey de resultados del pipeline de CI: del disparador al fallo
Sigue las ejecuciones del pipeline desde el disparador hasta el resultado y la causa de cada fallo: tests inestables, regresiones reales, configuración y entorno. Usa el historial de tu CI.
Un Sankey de pipeline de CI muestra cómo terminan las compilaciones según su disparador y por qué fallan. Separa los fallos que significan algo (una regresión) de los que no (un test inestable).
El ejemplo tiene 900 ejecuciones de pipeline de tres disparadores: pushes a main, pull requests y compilaciones nocturnas. 760 superan todas las etapas y 140 fallan, en la compilación (37), en los tests (96) o en el despliegue (7). La última columna da la causa: test inestable, regresión real, error de código, dependencia o configuración, y entorno de pruebas.
La tasa de éxito esconde la mezcla. En el ejemplo, 35 de los 96 fallos de tests son inestables, lo que es un problema de confianza en la batería de pruebas, y 45 son regresiones reales, que es el pipeline funcionando. Los recuentos son ejecuciones, no commits, así que un reintento es una ejecución. Para la etapa de revisión anterior, consulta /es/sankey/pull-request-review-flow, y /es/guides/como-encontrar-cuellos-de-botella-en-un-proceso-de-release-de-software para el proceso completo.
Cómo leer este diagrama
- 760 de 900 ejecuciones (84 %) superan todas las etapas; 140 (16 %) fallan.
- Los tests son el punto de fallo más habitual: 96 de 140 fallos (69 %).
- 35 fallos son tests inestables, el 25 % de todos los fallos, y 45 son regresiones reales.
- Las ejecuciones de pull request pasan el 82 % de las veces (410 de 500), las de main el 90 % (270 de 300).
Los datos detrás del diagrama
Cifras inventadas con fines ilustrativos. No son datos de ninguna empresa, equipo o sistema reales.
| Desde | Hacia | Cantidad (ejecuciones de pipeline) |
|---|---|---|
| Push a main | Superó todas las etapas | 270 |
| Push a main | Falló en la compilación | 8 |
| Push a main | Falló en los tests | 17 |
| Push a main | Falló en el despliegue | 5 |
| Pull request | Superó todas las etapas | 410 |
| Pull request | Falló en la compilación | 25 |
| Pull request | Falló en los tests | 65 |
| Nocturna | Superó todas las etapas | 80 |
| Nocturna | Falló en la compilación | 4 |
| Nocturna | Falló en los tests | 14 |
| Nocturna | Falló en el despliegue | 2 |
| Falló en la compilación | Error de código | 15 |
| Falló en la compilación | Dependencia o configuración | 22 |
| Falló en los tests | Test inestable | 35 |
| Falló en los tests | Regresión real | 45 |
| Falló en los tests | Entorno | 16 |
| Falló en el despliegue | Dependencia o configuración | 3 |
| Falló en el despliegue | Entorno | 4 |
Los mismos datos en CSV
source,target,value
Push a main,Superó todas las etapas,270
Push a main,Falló en la compilación,8
Push a main,Falló en los tests,17
Push a main,Falló en el despliegue,5
Pull request,Superó todas las etapas,410
Pull request,Falló en la compilación,25
Pull request,Falló en los tests,65
Nocturna,Superó todas las etapas,80
Nocturna,Falló en la compilación,4
Nocturna,Falló en los tests,14
Nocturna,Falló en el despliegue,2
Falló en la compilación,Error de código,15
Falló en la compilación,Dependencia o configuración,22
Falló en los tests,Test inestable,35
Falló en los tests,Regresión real,45
Falló en los tests,Entorno,16
Falló en el despliegue,Dependencia o configuración,3
Falló en el despliegue,Entorno,4Cómo funciona
Exporta las ejecuciones del pipeline de un periodo
Incluye el disparador, la primera etapa que falló y el resultado. Mantén los reintentos como ejecuciones separadas.
Etiqueta la causa de cada fallo
Usa una lista corta: inestable, regresión, error de código, configuración, entorno. Un fallo sin causa va a Desconocida, lo cual merece mostrarse.
Cuenta disparador, resultado y causa
Cuenta cada ejecución una vez, por su primera etapa fallida.
Comprueba el balance
Cada etapa fallida debe sacar tantas ejecuciones como entraron. Superadas termina en la segunda columna.
Preguntas frecuentes
¿Cómo distingo un test inestable de una regresión?
Una regla habitual es que un test que falla y luego pasa al reintentar sin cambios de código es inestable. Usa la regla que ya tenga tu equipo y mantenla igual cada periodo.
¿Por qué contar ejecuciones y no commits?
Las ejecuciones son lo que registra el sistema de CI. Si quieres commits, cuenta cada commit una vez por su resultado final y dilo en la nota de datos.
Edita este Sankey de pipeline de CI
Abre el ejemplo como gráfico propio e introduce los recuentos de tu pipeline.