Comment Spotify contient l'empreinte de ses applications

Spotify a doté son intégration continue de plusieurs contrôles destinés à limiter les changements accroissant trop sensiblement la taille de ses apps mobiles.

Des applications plus légères, donc moins polluantes ? Spotify a appliqué cette approche à ses clients iOS et Android. Et estimé pouvoir réduire de 650 t leur empreinte carbone annuelle combinée en diminuant de 1 Mo la taille de chacun.

Au-delà de l’empreinte environnementale, la démarche a d’autres motivations, illustrées notamment par une étude de Google. L’augmentation de la taille des apps mobiles y est corrélée à la baisse du taux d’installation (- 1 % tous les 6 Mo supplémentaires).

Spotify a inclus, dans son pipeline d’intégration continue, une vérification obligatoire de tous les Pull Request (PR) sur les dépôts concernés. Elle exploite la suite Emerge Tools. Principe : dès lors qu’une modification accroît de plus de 50 ko la taille d’une application, on la bloque. Une équipe l’étudie et choisit ou non de la valider. Des infos sur les PR finalement fusionnés remontent sur un canal Slack dédié. Y apparaissent aussi, inversement, des notifications sur les PR qui réduisent la taille d’une app de plus de 50 ko.

Un contrôle par unité de compilation

Si beaucoup de PR ne dépassent pas le seuil fixé, leur accumulation peut finir par alourdir nettement la taille des apps. Face à cet enjeu, Spotify a mis en place un autre contrôle. Il évalue le poids de chaque build sur deux aspects : au téléchargement et après installation. Le tout est segmenté par unité de compilation. Puis enrichi d’informations collectées dans la codebase par l’intermédiaire de scripts internes. Et groupé en modules dont des équipes endossent la responsabilité.

La plupart des PR « problématiques » se corrigent facilement, affirme Spotify. La source du problème n’est cependant pas toujours dans le code. Elle peut tenir à une particularité de fonctionnement d’un langage, voire d’un OS. Auquel cas tenter des corrections est plus risqué. Dans certains cas – typiquement, lors de l’ajout d’une fonctionnalité majeure -, on ne peut tout simplement pas éviter le phénomène.