SoundCloud a testé chaque version de JVMKit contre tous ses services dépendants au préalable

La bibliothèque JVMKit de SoundCloud fournissait des patrons JVM partagés — échafaudage de services, intégration base de données et Kafka, métriques — à des centaines de services internes en Scala, Java, Clojure et JRuby. À mesure que l'adoption croissait, l'équipe plateforme a perdu la visibilité sur les services qui dépendaient de quelles parties de l'API de JVMKit, rendant chaque version un pari : une mise à jour de routine pouvait silencieusement casser des services que l'équipe ne savait même pas affectés.

Parce que les dépendances chez SoundCloud étaient déclarées explicitement dans le fichier de build de chaque dépôt (sbt pour la JVM, Gradle pour Android, npm pour le web), l'équipe a indexé chaque dépôt avec Zoekt, un moteur de recherche de code basé sur les expressions régulières, rafraîchi toutes les cinq minutes. Une simple requête sur les fichiers de build listant JVMKit comme dépendance produisait un graphe de dépendances inversées en direct — chaque service qui serait affecté par un changement de JVMKit, généré automatiquement plutôt que suivi à la main.

Avec ce graphe en main, l'équipe a construit un pipeline de vérification : pour chaque service dépendant, cloner le dépôt, le compiler et le tester sans modification pour établir une base de référence, puis remplacer par la version candidate de JVMKit, appliquer les correctifs scriptés pour les changements d'API cassants connus, et compiler et tester à nouveau. Si la base de référence passait mais que la candidate échouait, le changement de JVMKit était la cause, et non une rupture préexistante dans ce service. La vérification s'exécutait chaque nuit sur l'ensemble complet des dépendants et sur chaque pull request contre un sous-ensemble plus rapide figurant sur une liste d'autorisation.

Compiler et tester chaque appelant avant de livrer la bibliothèque

Cela a remplacé un processus manuel et sujet aux erreurs (livrer, attendre que les équipes se plaignent) par une vérification automatique et falsifiable qui s'exécute avant que la version ne soit livrée.

L'exécution préalable d'une base de référence non modifiée permettait d'isoler si une défaillance provenait du changement de JVMKit ou d'un service déjà cassé ce jour-là.

La division de la vérification en une exécution complète nocturne et une exécution rapide limitée aux PR maintenait un retour rapide sans omettre la couverture complète.

Le graphe de dépendances inversées était généré à partir du code, non maintenu à la main, de sorte qu'il restait exact à mesure que des services étaient ajoutés ou retirés.

Lorsqu'une bibliothèque interne se trouve sous des centaines de services, ne livrez pas en espérant — rendez le graphe de dépendances interrogeable et laissez la CI tester d'abord chaque appelant en aval.

JVMKit a continué d'alimenter des centaines de services et des milliers d'instances de production chez SoundCloud. Avec le pipeline de vérification en place, l'équipe plateforme a rapporté livrer JVMKit plus souvent, avec des défaillances traçables jusqu'à une étape précise et une cause précise plutôt que se manifestant comme une panne inexpliquée en aval.