Ramp a réduit sa suite de tests de 45 minutes à moins de 5 minutes en misant sur des paris asymétriques

En juillet 2023, la suite de tests du monolithe Python de Ramp prenait 45 minutes à s'exécuter, et la lenteur des tests engorgeait la file de fusion dans toute l'entreprise — les ingénieurs bloquaient une demi-journée rien que pour surveiller les modifications en attente. Deux ans plus tôt, un article interne avait déjà signalé que la lenteur des tests nuisait à la productivité des ingénieurs, mais rien n'avait été fait depuis.

Plutôt que de s'engager dans une grande réécriture, l'équipe a d'abord mesuré : environ 38 des 45 minutes provenaient de l'invocation de pytest elle-même. Le profilage a montré que l'exécution des tests était limitée par le CPU, si bien que le tout premier correctif — des CPU plus rapides — a à lui seul réduit le temps d'exécution d'environ 50 %, le plus grand gain isolé de tout le projet et celui qui a demandé le moins d'efforts à trouver.

À partir de là, les ingénieurs se sont répartis et ont mené en parallèle des expériences peu coûteuses, limitées à ce sur quoi chacun avait déjà du contexte : la mise en cache des couches Docker sur des runners auto-hébergés a fait gagner plus d'une minute ; un algorithme de répartition du travail pytest-xdist réécrit a fait gagner 2 à 3 minutes ; davantage de bases de données de test et des paramètres de connexion Postgres ajustés ont résolu la contention de verrous une fois que plus de 20 workers ont frappé la même base de données. Toutes les expériences n'ont pas porté leurs fruits — le montage des données de test en RAM n'a apporté aucun gain et a été abandonné — mais chacune était assez peu coûteuse pour valoir la tentative.

Poursuivre des expériences peu coûteuses à fort potentiel, et s'arrêter dès que les gains diminuent

Mesurer d'abord (38 des 45 minutes correspondaient à l'appel pytest lui-même, limité par le CPU) a permis à l'équipe de corriger le véritable goulot d'étranglement au lieu de deviner.

Réaliser d'abord le correctif au meilleur rapport levier/effort (des CPU plus rapides, ~50 % de gain) a créé un élan et libéré du temps pour explorer des idées plus risquées.

Se diviser en expériences parallèles et peu coûteuses a permis à l'équipe de tester rapidement de nombreuses hypothèses au lieu de tout miser sur un seul grand changement.

Représenter graphiquement le temps gagné par changement a rendu visible la courbe des rendements décroissants, donnant à l'équipe un signal concret pour s'arrêter plutôt que de continuer à peaufiner pour des gains marginaux.

Mesurez avant d'optimiser, corrigez d'abord l'élément au meilleur levier, puis menez en parallèle un portefeuille d'expériences peu coûteuses — et utilisez la taille décroissante de chaque gain comme signal pour vous arrêter.

Au bout d'une semaine, la suite s'exécutait en moins de 5 minutes, soit une réduction d'environ 70 % ou plus par rapport aux 45 minutes initiales. Les nouvelles améliorations en fin de semaine ne retranchaient plus que quelques secondes (moins de 5 %) au temps d'exécution, ce que l'équipe a utilisé comme signal pour s'arrêter et déplacer les idées restantes dans un backlog de longue traîne plutôt que de continuer à optimiser.