Amélioration continue de la productivité des développeurs chez Snowflake

Les gens me demandent souvent : « Pourquoi avez-vous rejoint Snowflake et pourquoi avez-vous choisi de travailler sur la productivité des développeurs ? ». J’ai rejoint Snowflake pour apprendre avec des ingénieurs de classe mondiale et faire partie de la culture hautement collaborative. Ceux-ci ont été la sauce secrète de la croissance phénoménale de Snowflake. Snowflake se lançait dans une transformation remarquable de la productivité des développeurs, et j'ai dû sauter sur le vaisseau fusée au moment où il décollait !

Commençons par le début. En 2012, Benoît Dageville et Thierry Cruanes fondent Snowflake. Ingénieurs expérimentés dans le domaine des bases de données, ils ont écrit une grande partie du code qui alimente encore Snowflake aujourd’hui. Nos fondateurs pensent que chaque ingénieur devrait écrire du code, quelle que soit son ancienneté. Avoir les mains dans le cambouis permet à nos architectes confirmés et CTO de voir la réalité sur le terrain de la productivité des développeurs et de comprendre plus précisément les difficultés quotidiennes, la faisabilité des calendriers et les compromis entre les solutions.

Snowflake a connu une croissance rapide et a embauché les meilleurs talents, ce qui a entraîné une croissance rapide de la base de code. En tant qu’entreprise à produit unique, le produit Snowflake est inévitablement devenu plus complexe et riche en fonctionnalités au fil du temps. Par conséquent, au fil des ans, notre collatéral de test s’est développé sans contrôle, l’environnement de développement est devenu de plus en plus complexe et les délais de build et de test ont considérablement ralenti, ce qui a eu un impact négatif sur la productivité des développeurs. De plus, l’infrastructure sous-jacente n’était pas fiable sous une forte charge, ce qui nécessitait des reprises manuelles et frustrait les développeurs avec une perte de productivité. Malgré les premiers efforts, la centralisation et la mise à l’échelle de nos outils se sont avérées infructueuses.

Au début de 2023, nous avons lancé des initiatives visant à améliorer l’intégration continue et les environnements de développement, mais elles n’ont progressé que lentement. Fin 2023, la stratégie devait être repensée pour la faire avancer.

Nous avons identifié quatre éléments clés pour cela : la priorité en matière de leadership, la mesure, les liens avec les clients et la responsabilité.

Priorité en matière de leadership

Notre direction définit la productivité des développeurs comme une priorité absolue pour l’ensemble de l’entreprise, avec des examens mensuels du CEO et de l’équipe de direction. Le CTO de Snowflake, S Muralidhar, participe activement à la définition des objectifs à l’échelle de l’entreprise et à la direction des équipes exécutantes. La productivité des développeurs a augmenté les effectifs de l’équipe. En attendant, des bénévoles dans toute l’entreprise se sont mobilisés pour le refactoring du code et pour améliorer les temps d’installation et d’exécution des tests afin d’accélérer la refonte de notre système de build et de nos environnements de développement. 

Mesure

La mesure est essentielle pour comprendre si nous progressons. Il est essentiel de mesurer la réussite telle qu’elle est perçue du point de vue d’un client, et non notre capacité à franchir des étapes internes. Pour ce faire, nous recueillons une combinaison d’indicateurs qualitatifs et quantitatifs :

• Métriques des opérations produit : temps de fonctionnement du système de build ; nombre total de commandes du système de build par jour

• Indicateurs du produit perçu par les utilisateurs : temps de latence pour construire et tester ; pourcentage d’espaces de travail sains ; adoption de nouveaux systèmes 

• Indicateurs d’output du parcours utilisateur : nombre moyen de PR par développeur et par semaine ; latence du cycle de vie des PR à chaque étape depuis la soumission des PR, la première révision et la dernière révision jusqu’à la fusion

• Opinion globale des développeurs : CSAT trimestriels (sur sondage) ; principaux domaines de difficulté

Nous fixons des objectifs trimestriels ambitieux basés sur des indicateurs et nous les surveillons de près. Lors de notre bilan hebdomadaire des opérations, nous analysons en détail les anomalies des indicateurs et poursuivons la résolution. Lorsque les indicateurs ne sont pas suffisamment reliés à l’expérience du développeur, nous les révisons et recueillons des commentaires d’utilisateurs mis à jour pour assurer la cohérence avec l’expérience vécue par les utilisateurs.

Liens avec les clients

Nos clients sont des ingénieurs Snowflake exigeants. Pour mériter leur confiance et construire le cercle vertueux des retours et des itérations, nous devons démontrer que nous 1) comprenons leurs expériences, 2) faisons des progrès constants et 3) redéfinissons les priorités et les itérations en fonction de leurs retours.

Lorsqu’ils exigent des changements, nos clients se divisent en trois catégories : les utilisateurs précoces, les adeptes et les retardataires. Les utilisateurs précoces jouent un rôle clé dans la rétroaction critique pour nous aider à itérer, et ils font la promotion de l’innovation auprès de leurs équipes en tant qu’initiés de confiance pour favoriser l’adoption. Nous avons identifié les utilisateurs précoces comme des champions dans chaque équipe et nous avons mené des entrevues régulières pour garder un œil sur les progrès et les opinions. 

Nous avons analysé les commentaires des utilisateurs dans les enquêtes trimestrielles en tant qu’outil clé pour prioriser la planification trimestrielle. Nous avons mené de fréquents entretiens avec des utilisateurs de différents groupes de produits, en analysant par ancienneté, langages de programmation principaux et emplacements géographiques. Nous avons utilisé ces commentaires pour affiner les priorités dans les sprints mensuels. Comme chaque emplacement géographique diffère par son rythme d’équipe et son mode de communication préféré, nous sommes allés voir chaque équipe fonctionnelle pour comprendre quel serait le meilleur forum pour interagir avec les développeurs locaux. De plus, nous avons toujours bouclé la boucle avec nos clients pour leur faire part de l’avancement concernant leurs principaux points de friction et obtenir leurs commentaires sur la feuille de route.

Responsabilité

Nous avons traité les outils de développement comme un produit orienté client avec des accords de niveau de service publiés. Nous avons démontré notre responsabilité dans des e-mails hebdomadaires et des points bimensuels sur les produits. La transparence contribue à renforcer la confiance de nos clients et à assurer la circulation des commentaires. 

Nous avons pu réaliser des progrès grâce à la mesure, valider les améliorations grâce à la connexion avec nos clients et faire preuve de responsabilité en faisant le point avec nos clients. L’accent a été mis sur l’accélération du développement et de l’adoption de quatre innovations : Bazel (système de build), l’espace de travail cloud (environnement de développement), SnowCI (intégration continue) et Snowfort (environnement de test de régression). Chacun des quatre domaines d’innovation nous a permis de surmonter des défis techniques et organisationnels.

Bazel

Nos systèmes de build hérités, Maven et CMake, ont entraîné une prolifération de scripts de builds et d’outils incohérents, ce qui a accentué la courbe d’apprentissage pour les développeurs travaillant sur différents composants. Les builds locales n’étaient pas fiables et nécessitaient de fréquents essais et des « builds propres » pour réussir, ce qui a entraînait une forte frustration des développeurs. En adoptant Bazel, nous avons obtenu des builds cohérentes, fiables et rapides. De plus, l’exécution backend à distance sur Buildbarn nous a permis de paralléliser massivement les builds et les tests, ce qui a considérablement réduit la latence.

Espace de travail cloud

L’ancien environnement de développement sur MacBook VM avait du mal à répondre à la demande croissante de conception et de test du produit. Les utilisateurs étaient limités à une machine virtuelle active à la fois, et la réinitialisation d’une machine virtuelle rompue pouvait prendre 30 minutes et parfois beaucoup plus. Pour y remédier, nous avons introduit des espaces de travail cloud éphémères exécutés sur Kubernetes, préchargés avec le dernier code checkpoint, les builds en cache, l’IDE, les outils de test et tout ce dont l’utilisateur aurait besoin pour une productivité instantanée. Un utilisateur peut déployer un espace de travail en deux minutes et gérer plusieurs espaces de travail en parallèle, avec une connexion intra-data-center rapide directement au cache Bazel Buildbarn. 

La migration de l'environnement de développement est le changement le plus perturbateur pour les flux de développement. Pour favoriser l’adoption, il fallait plus qu’un excellent produit pour surmonter l’inertie. Nous avons mis à profit les utilisateurs de la première heure en tant que sponsors internes, utilisé des modes de contact amusants et créatifs pour motiver les retardataires, nous sommes allés voir chaque équipe pour démontrer les avantages et nous avons bouclé la boucle avec plusieurs phases de commentaires.

SnowCI

Historiquement, notre système CI était alimenté par des scripts Jenkins tentaculaires et incohérents, qui s’étaient développés au fil des ans. La correction et l’optimisation de ces données étaient difficiles en raison de faibles capacités de test et d’une compréhension limitée par l’équipe de l’ensemble de la configuration du système. En concevant en interne un système propre basé sur YAML, nommé SnowCI, pour alimenter nos flux de travail CI, nous avons forcé un nettoyage de ces scripts et sommes passés à un système CI beaucoup plus compréhensible, conventionnel et moderne. Cela nous a permis de mesurer constamment les étapes de l’intégration continue, de supprimer de larges portions de flux de travail personnalisés et peu fiables et de nous concentrer sur la vitesse et la fiabilité comme principes fondamentaux.

Snowfort

Notre framework de test hérité a été créé il y a plus de dix ans, sans isolation pour permettre aux tests de commencer et de se terminer dans un état propre, sans garde-fous pour éviter les incohérences et sans abstraction pour empêcher le code de configuration boilerplate en double. C’est pourquoi nous avons créé Snowfort, le framework de test de régression de Snowflake, pour remédier à ces lacunes. Cela nous a également permis de diviser de grosses ressources collatérales de test en petits batchs, ce qui a permis de retenter rapidement les essais en cas d’échec. Buildbarn nous a permis de paralléliser l’exécution des tests, réduisant ainsi la latence CI. L’isolement des tests nous a permis de réduire considérablement la fragilité des tests, améliorant ainsi la fiabilité de l’intégration continue.

Progrès

Entre février et décembre 2024, l’adoption des quatre nouveaux systèmes est passée de 10 - 20 % à 90 - 95 %. La build est désormais beaucoup plus fiable et stable avec une latence de huit minutes. La latence et la fiabilité de l’intégration continue à différents stades du pipeline ont été multipliées par trois ou six. Les environnements de développement éphémères se déploient avec des builds et des outils entièrement en cache en deux minutes, préservant entièrement les paramètres entre les sessions. Le framework de test de régression Snowfort facilite la création de tests fiables avec une isolation appropriée. Par conséquent, l’opinion des développeurs s’est considérablement améliorée. En neuf mois, le pourcentage de clients insatisfaits est passé de 58,9 % à 21,4 %, et le pourcentage de clients satisfaits est passé de 17,8 % à 42,3 %.

Notre travail n’est pas terminé. Nous avons beaucoup de travail devant nous pour rendre l’expérience des développeurs fluide et encore plus agréable. Nous investissons dans la stratégie Bazel et IDE afin d’avoir des builds locales en moins d’une minute et une expérience fluide de création et de débogage pour chaque langage de programmation chez Snowflake. Nous investissons dans SnowCI pour compléter les PR, de la création à la fusion, en moins de vingt minutes. Grâce aux quatre ingrédients clés mentionnés ci-dessus, nous sommes en bonne position pour continuer à servir nos clients.