Ramp redujo su suite de pruebas de 45 minutos a menos de 5 minutos apostando por mejoras asimétricas

En julio de 2023, la suite de pruebas del monolito de Python de Ramp tardaba 45 minutos en ejecutarse, y las pruebas lentas estaban obstruyendo la cola de fusiones en toda la empresa: los ingenieros bloqueaban medio día solo para vigilar los cambios pendientes. Dos años antes, una publicación interna ya había señalado que las pruebas lentas perjudicaban la productividad de los ingenieros, pero no se había hecho nada desde entonces.

En lugar de comprometerse con una gran reescritura, el equipo primero midió: alrededor de 38 de los 45 minutos provenían de la propia invocación de pytest. El perfilado mostró que la ejecución de las pruebas estaba limitada por la CPU, por lo que la primera corrección —CPUs más rápidas— redujo el tiempo de ejecución aproximadamente un 50% por sí sola, la mayor ganancia individual de todo el proyecto y la que menos esfuerzo requirió encontrar.

A partir de ahí, los ingenieros se dividieron y ejecutaron experimentos baratos en paralelo, acotados a aquello sobre lo que cada uno ya tenía contexto: el almacenamiento en caché de capas de Docker en runners autoalojados ahorró más de un minuto; un algoritmo de reparto de trabajo de pytest-xdist reescrito ahorró 2-3 minutos; más bases de datos de prueba y una configuración ajustada de conexiones de Postgres resolvieron la contención de bloqueos una vez que más de 20 workers accedían a la misma base de datos. No todos los experimentos dieron resultado: montar los datos de prueba en RAM no mostró ninguna ganancia y se descartó, pero cada uno era lo suficientemente barato como para valer la pena intentarlo.

Perseguir experimentos baratos con alto potencial de beneficio y detenerse en el momento en que las ganancias disminuyen

Medir primero (38 de 45 minutos eran la propia llamada a pytest, limitada por la CPU) hizo que el equipo corrigiera el cuello de botella real en lugar de adivinar.

Hacer primero la corrección de mayor impacto y menor esfuerzo (CPUs más rápidas, ~50% de ganancia) generó impulso y liberó tiempo para explorar ideas más arriesgadas.

Dividirse en experimentos paralelos de bajo costo permitió al equipo probar muchas hipótesis rápidamente en lugar de apostarlo todo a un único cambio grande.

Graficar el tiempo ahorrado por cambio hizo visible la curva de rendimientos decrecientes, dando al equipo una señal concreta para detenerse en lugar de seguir puliendo en busca de ganancias marginales.

Medir antes de ajustar, corregir primero el elemento de mayor impacto y luego ejecutar una cartera de experimentos baratos en paralelo, y usar el tamaño decreciente de cada ganancia como señal para detenerse.

Después de una semana, la suite se ejecutaba en menos de 5 minutos, aproximadamente una reducción del 70%+ respecto de los 45 originales. Las nuevas mejoras al final de la semana solo recortaban segundos (menos del 5%) del tiempo de ejecución, lo que el equipo usó como señal para detenerse y trasladar las ideas restantes a un backlog de largo plazo en lugar de seguir ajustando.