Cómo encontrar cuellos de botella en un proceso de release de software
Dibuja el proceso de release como diagrama de flujo, cuenta lo que sale de cada decisión y muestra los recuentos en un diagrama de Sankey. Encuentra la puerta donde las builds fallan, vuelven o esperan más.
Un cuello de botella en una release es la puerta donde el trabajo se acumula, falla o regresa. Esta guía dibuja primero el proceso, de modo que cada puerta sea una decisión con salidas con nombre, y luego cuenta las releases por esas salidas.
En resumen
- Dibuja el proceso como decisiones con salidas etiquetadas antes de contar nada.
- Cuenta las releases (o builds) que salen por cada salida en un periodo.
- Una puerta con una rama de retorno ancha es un cuello de botella, aunque sea rápida.
- Muestra los recuentos en un diagrama de Sankey y usa el diagrama de flujo para explicarlos.
Empieza por las puertas, no por los números
Los equipos suelen buscar el paso lento promediando duraciones. Eso encuentra tareas lentas, pero no las puertas que mandan el trabajo hacia atrás. Una release puede pasar un día en pruebas y aun así perder una semana, porque una prueba fallida la devuelve a un paso de corrección y el ciclo vuelve a empezar. Para verlo, dibuja el proceso con sus decisiones y cuenta cuántas releases toman cada salida.
Un diagrama de flujo da la estructura: cada decisión tiene ramas con etiqueta y cada rama tiene un recuento. El ejemplo es un proceso de release con cuatro decisiones: pruebas automáticas, go o no-go, estado de producción y defectos en producción. Con los recuentos por rama, un diagrama de Sankey los muestra como anchos. Consulta /es/sankey/ci-pipeline-outcomes para la etapa de compilación y /es/sankey/pull-request-review-flow para la etapa de revisión que la precede.
Sé prudente con las afirmaciones. Los recuentos muestran dónde sale el trabajo de una puerta, no por qué. El motivo sale de leer los elementos fallidos y de hablar con quienes gestionan la puerta.
Un proceso de release, construido por etapas
Veinte pasos y cuatro decisiones. Cada decisión es un lugar donde un Sankey mostraría el trabajo saliendo en dos direcciones.
Compilación y pruebas automáticas
El proceso empieza con el código completo, congela el alcance y ejecuta las pruebas automáticas. La primera decisión, «¿Pasan las pruebas automáticas?», tiene una rama Fallan que vuelve por un paso de corrección hasta la compilación. Ese bucle es el primer lugar que contar.
Preproducción, aprobación y decisión go
Una build que pasa va a preproducción, regresión y UAT, y se reúne y aprueba el expediente de preparación. «¿Go o no-go?» tiene una rama No-go que vuelve al paso de corrección, así que una release puede regresar desde muy avanzado el proceso.
Producción y el camino de vuelta
La release se despliega en su ventana y se prueba con pruebas de humo. «¿La release es estable?» se divide entre vigilar o una reversión que vuelve al paso de corrección. Revertir es la salida más cara, así que su recuento es el que más importa.
Seguimiento y hotfix
Tras el periodo de observación, «¿Defecto en producción?» manda la release a un hotfix, que reentra en el despliegue, o a las notas de versión y el cierre. Cuenta con qué frecuencia se toma la rama del hotfix.
Cómo funciona
Dibuja el proceso con sus decisiones
Pon cada puerta como una decisión con salidas etiquetadas, como Pasan y Fallan. Una puerta dibujada como paso simple esconde la salida que quieres contar.
Elige un periodo y una unidad
Toma el último trimestre y cuenta releases, o builds si publicas a menudo. Di cuál en la nota de datos.
Cuenta lo que sale de cada decisión
Para cada decisión, cuenta cuántos elementos tomaron cada salida. Saca los números de tu sistema de CI, tus tickets o el registro de releases.
Dibuja los recuentos como diagrama de Sankey
Usa las decisiones como nodos y las salidas como flujos. Comprueba que lo que entra en cada nodo es igual a lo que sale.
Lee primero la rama de retorno más ancha
La rama más ancha que apunta hacia atrás es el probable cuello de botella. Lee esos elementos para saber por qué.
Errores que debes evitar
Contar solo el resultado final
Si solo cuentas lo que se publicó, los bucles desaparecen. Cuenta en cada decisión o el Sankey mostrará un proceso fluido que no ocurrió.
Mezclar unidades
Builds, releases y tickets son unidades distintas. Elige una para todo el gráfico y dilo.
Leer los recuentos como causas
Una rama Fallan ancha dice que las pruebas fallan a menudo, no por qué. Mira los elementos fallidos antes de cambiar el proceso.
Abre el diagrama de flujo de release de software
Abre la plantilla de release, adapta las puertas a las tuyas y cuenta las salidas.
Guías relacionadas
Preguntas frecuentes
¿Por qué dibujar un diagrama de flujo si solo quiero un Sankey?
Porque el diagrama de flujo decide cuáles son los nodos. Sin él, el Sankey muestra las etapas que tu herramienta exporta, que a menudo no son las puertas donde la gente decide.
¿Cuántas releases necesito?
Las suficientes para que cada salida tenga más de unos pocos elementos. Con menos de unos 20, muestra los recuentos en una tabla en vez de un gráfico.
¿Sustituye esto a medir el lead time?
No. El lead time dice cuánto tarda; el Sankey dice dónde sale o regresa el trabajo. Usa ambos y compáralos para el mismo periodo.