Étude de cas

Spotify & GitHub

Peut-être vous souvenez-vous de l’époque où, pour écouter de la musique tout en vous déplaçant, vous deviez tomber sur la bonne station de la radio, synchroniser votre lecteur MP3 ou retrouver la bonne chanson sur votre baladeur. Il est facile d’oublier ces années pas si lointaines que ça, alors que tant de musiques sont aujourd’hui disponibles en quelques clics. Musique, livres audio, podcasts et bien d’autres peuvent être diffusés en streaming sur toutes les plateformes dans le monde entier. Derrière les incroyables avancées de l’industrie du streaming se cachent des décennies de prouesses techniques : accès Internet, formats de fichiers, algorithmes et bien d’autres encore.

Ces 10 dernières années, Spotify a su se développer au fil de ces progrès pour atteindre 217 millions d’utilisateurs actifs. De petite startup suédoise, l’entreprise s’est peu à peu imposée comme l’une des plus importantes plateformes de streaming musical et son expérience utilisateur intégrée est devenue une référence. Les utilisateurs peuvent écouter leur musique n’importe où et n’importe quand, sur iOS ou Android. Au bureau, ils peuvent se rendre sur le site de Spotify via leur navigateur ou bien opter pour l’application disponible sur Mac, Windows ou Linux. A la maison, ils peuvent écouter leur musique préférée depuis un appareil intelligent : enceintes connectées, assistants virtuels, barres de son et autres. Quel que soit l’endroit où leurs utilisateurs se trouvent, le logiciel de Spotify doit fonctionner sans rencontrer de problème. Il en va de même pour tous les collaborateurs de l’entreprise, qui travaillent aux quatre coins du monde.

La différenciation produit et l’expérience utilisateur sont deux domaines clés dans l’industrie très concurrentielle du streaming. Avec une gamme de fonctionnalités toujours plus importante, l’équipe de développement de Spotify a besoin de collaborer pour s’assurer que tout, du client à l’infrastructure back-end, fonctionne de façon harmonieuse. Et, pour une marque centrée sur le client, il est essentiel que rien ne tombe en panne lors de la sortie régulière de mises à jour. Laurent Ploix, responsable produit, travaille sur la mise en œuvre d’outils, de méthodologies et de systèmes permettant aux développeurs (et à leur code) de travailler sans encombre.

Chez Spotify, l’équipe et les développeurs de Laurent Ploix utilisent GitHub Enterprise Server pour les projets en innersource et pour collaborer. Ils collaborent également sur GitHub Enterprise Cloud afin de partager leur code et leur travail en toute sécurité avec des partenaires externes et participer à la communauté open source. Avec des méthodes proches de l’open source, l’équipe a pu apprendre d’une large communauté de développeurs. Spotify a une expérience directe du monde open source puisque c’est la base-même de certaines des fonctionnalités les plus connues de la plateforme. Pour alimenter les playlists « Découvertes de la semaine », basées sur des recommandations, l’équipe développe et maintient Scio, un projet en open source créé à partir d’Apache Beam. Cette technologie leur permet de calculer les recommandations de centaines de millions d’utilisateurs et de lancer le traitement de tâches complexes sur des milliers de machines en même temps. Scio, qui joue un rôle primordial pour la plateforme, reste pour autant un projet open source car l’équipe croit en ce modèle. Des milliers de contributeurs peuvent apporter leurs suggestions, et cette diversité permet d’aboutir à des idées plus robustes.

Pour transposer l’innovation open source dans ses projets, Spotify a recours à l’innersource. L’innersource permet aux développeurs de travailler sur des projets internes comme s’ils étaient en open source : ils collaborent ouvertement, apprennent les uns des autres et réutilisent le code dans toute l’entreprise. « Nous encourageons nos équipes à apporter leur contribution au code des autres collaborateurs », explique Laurent Ploix. « Au lieu de soumettre un ticket JIRA et d’attendre une réponse, tout le monde peut contribuer. »

Laurent Ploix considère que la responsabilité partagée mène à une meilleure qualité du code et à une livraison plus rapide. « Nous avons besoin de cultiver un sens de l’ouverture et une notion de responsabilité », affirme-t-il. « Lorsque les développeurs sont responsables de leur code, ils ne le modifient pas pour les autres et ne travaillent pas uniquement sur ce bout de code. Mais ça veut dire qu’ils y tiennent beaucoup. La qualité est au cœur de leurs préoccupations, ils en sont fiers. » Et Laurent Ploix de poursuivre, à propos des développeurs de Spotify souhaitant apporter leur contribution : « les pull requests sont les bienvenues. Il est possible qu’une autre personne trouve une meilleure solution que moi. »

Au final, les équipes responsables de projets sur Spotify assument des rôles similaires à certains mainteneurs open source. Elles reçoivent et trient les nouveaux bugs, les nouvelles idées et les nouveaux codes. Elles peuvent également être responsables de l’abandon ou de l’archivage de leurs projets. Selon Ploix, « ces équipes peuvent devenir des mainteneurs, sans aucun doute. Grâce à une forte notion de responsabilité, nous évitons d’accumuler du code sans que personne ne sache s’il est utilisé ou pas. »

Notre objectif est de réduire la surcharge d’information. Les développeurs peuvent recevoir de nombreuses informations de la CI, mais ils ont besoin de plus qu’un statut “Réussi” ou “Échec” pour prendre des décisions informées. Nous souhaitons que les développeurs sachent exactement comment une modification peut influencer la base de code.

L’intégration continue (CI) est un élément central de l’écosystème de Spotify. Comme de nombreuses organisations, Spotify dépend de la CI en tant que processus interne pour réduire le temps et les efforts nécessaires à l’intégration de chaque fonctionnalité, et pour réussir à produire une version du produit pouvant être livrée à tout moment. « La CI est importante d’un point de vue du développement commercial », affirme-t-il.

Pour s’assurer du respect des bonnes pratiques de développement que sont les itérations rapides et incrémentales, l’équipe a créé des systèmes de CI qui s’intègrent avec GitHub Enterprise et qui fournissent aux développeurs les informations exactes dont ils ont besoin.

« Nos systèmes génèrent beaucoup de données et il est parfois difficile de trouver le feedback pertinent. Nos intégrations avec GitHub nous permettent de les faire apparaître dans la pull request et de réduire la boucle de feedback », déclare Marcus Forsell Stahre, Senior Engineer chez Spotify.

« Notre objectif est de réduire la surcharge d’information », indique Laurent Ploix. Les développeurs peuvent recevoir de nombreuses informations de la CI, mais ils ont besoin de plus qu’un statut “Réussi” ou “Échec” pour prendre des décisions informées. Nous souhaitons que les développeurs sachent exactement comment une modification peut influencer la base de code. »

C’est là que les outils sur mesure et les webhooks entrent en jeu, mais Laurent Ploix envisage de rationaliser encore plus leur processus de revue de code avec l’API GitHub. Selon lui, l’API a le potentiel de transformer l’expérience développeur. « Nous utilisons de nombreux bots pour comprendre l’impact potentiel d’une pull request, mais cela a plutôt tendance à polluer la conversation. Nous souhaitons que cette information soit facile à interpréter et à intégrer à la prise de décision. C’est dans cette mesure que l’API Checks va nous aider. »

Pour Laurent Ploix, le processus peut toujours être perfectionné et même les plus petites améliorations peuvent avoir un impact important sur la qualité à l’échelle de l’entreprise. L’équipe possède un grand nombre de machines travaillant sur des builds et des tests en CI. Laurent Ploix explique que l’équipe travaille avec ces systèmes sur de nombreuses builds chaque jour. Et ce nombre ne cesse d’augmenter car un nombre croissant de développeurs apporte de nouvelles modifications.

Lorsque les développeurs de Spotify ont besoin d’aide, ils se tournent vers l’équipe support de GitHub Enterprise. « Nous comparons toujours le niveau de support que nous obtenons de la part des fournisseurs », affirme Laurent Ploix. « GitHub nous répond rapidement en apportant des informations claires sur ce qu’il se passe ; nous sommes vraiment très satisfaits. » L’équipe Spotify rencontre également régulièrement les Solutions Engineers de GitHub pour obtenir une assistance plus poussée, allant de questions concernant l’utilisation d’une API à des enjeux stratégiques plus vastes.

Plus l’entreprise se développe, plus il devient important d’obtenir une assistance rapide et complète, d’où l’intensification du recrutement des développeurs. Même dans une équipe se développant rapidement, Laurent Ploix a constaté que la plupart des développeurs connaissent GitHub. « Ils savent ce qu’est une pull request car c’est par ce biais qu’ils contribuent à des projets open source », indique-­t-il. « Une grande partie de nos développeurs maîtrise GitHub, parce qu’ils l’ont utilisé pour leur développement personnel ou dans leurs emplois précédents. Avec GitHub Enterprise, ils n’ont pas besoin d’être formés. »

Pour Laurent Ploix, qu’il s’agisse de nouveaux arrivants ou de collaborateurs chevronnés, tous bénéficient de l’utilisation d’un système de contrôle de version qu’ils connaissent et comprennent. Il apprécie également la liberté qu’ont les équipes de copier un projet existant et de travailler sur celui-ci sans modifier le code source original. Selon lui, « GitHub fournit un environnement propice à l’expérimentation qui permet aux développeurs de tester de nouvelles idées, sans craindre de casser des éléments fondamentaux. Ce type de créativité est encouragé, et il aide à faire de Spotify ce qu’il est aujourd’hui. »

  • Secteur

    Technologie / Streaming musical

  • Collaborateurs

    3 800 +

Utilisez GitHub dans votre entreprise

Des options d'hébergement flexibles à la sécurité enrichie par la data, donnez à vos équipes tous les outils pour développer au mieux.

Contacter notre équipe

Rejoignez la plus grande communauté de développeurs au monde

Free

Les bases pour les équipes et les développeurs

  • Repositories publics/ privés illimités
  • Nombre illimité de collaborateurs
  • 2000 minutes de Processing GitHub Actions par mois Les repositories publics sont gratuits
  • 500MB de stockage pour GitHub Packages Les repositories publics sont gratuits
  • Support de la communauté

$0 par mois

Je choisis Free

Team

Des outils de collaboration et de gestion avancés pour les équipes

  • Tout ce qui est inclus dans l'offre Free
  • Revue requise par un tiers
  • 3000 minutes de Processing GitHub Actions par mois Les repositories publics sont gratuits
  • 2 Go de stockage de paquets GitHub Les repositories publics sont gratuits
  • Propriétaires de codes

$4 par utilisateur/mois

Je choisis Team

Enterprise

Sécurité, conformité et déploiement pour les organisations

  • Tout ce qui est inclus dans l'offre Team
  • Authentification unique SAML (SSO)
  • 50 000 minutes de Processing GitHub Actions par mois Les repositories publics sont gratuits
  • 50 Go de stockage de paquets GitHub Les repositories publics sont gratuits
  • Audit avancé

$21 par utilisateur/mois

Contacter l'équipe des ventes

GitHub One

Tous nos meilleurs outils, support et services

  • Tout ce qui est inclus dans l'offre Enterprise
  • Une sécurité renforcée par la communauté
  • Des analyses de performance immédiatement exploitables
  • Un soutien 24h/24 et 7j/7
  • Un apprentissage continu