Comment Facebook maintient ses millions de lignes de code
Sur son blog à destination des développeurs, Facebook vient de publier un long article détaillant les travaux d'optimisation que ses équipes ont réalisés autour de Mercurial. Le réseau social a en effet préféré cet outil de build open source à Git ou Subversion pour gérer l'ensemble des dépôts de ses projets de développement. Il a choisi Mercurial notamment pour l'architecture de ce dernier, plus en phase avec la gestion de volume de code massif. Car la gestion de build de Facebook est à l'image du gigantisme de son site web. Centralisée, elle peut être qualifiée de Big Data.
"Avec des milliers de modifications réalisées chaque semaine sur des centaines de milliers de fichiers, nous gérons un dépôt de code source énorme. En 2013, il représente 17 millions de lignes de code et 44 000 fichiers vérifiés", confirme Durham Goode, développeur chez Facebook. Le ton est donné.
Plus performant que Git pour la gestion de code en masse
Utilisateur de Subversion, Facebook a décidé de migrer vers Mercurial il y a deux ans, et de centraliser l'ensemble de ses codes dans cet outil décentralisé de révision de versions. Entre Git et Mercurial, le groupe a donc sélectionné le second, même si les deux outils ne pouvaient prétendre en l'état supporter les volumes de code de l'ensemble de ses projets. La raison de ce choix : l'architecture de Mercurial, et ses API de plus bas niveau (interagissant directement sur son serveur de code) semblaient plus appropriées à cet environnement de développement massif.
Partant de là, Facebook s'est lancé dans un long travail d'optimisation de Mercurial. Ses équipes ont notamment développé de nouveaux algorithmes pour améliorer la performance des builds sur de très grands repositories. L'application a également été réécrite en C, toujours dans un souci de performance.
L'une des principales optimisations a notamment consisté à rationnaliser la manière de gérer la mise à jour du code. La méthode utilisée ? Eviter à l'application de parcourir l'ensemble des sources pour déterminer si un code a été modifié, mais ne réserver ce calcul (pouvant être assez lourd sur des milliers de fichiers) qu'aux documents dont le statut de mise à jour a changé dans le système de monitoring de fichiers de la plate-forme de build (Watchman). Grâce à cette amélioration, "les commandes de mise à jour de Mercurial sont cinq fois plus rapides que les commandes de mise à jour de Git", argue Durham Goode.
Une charge serveur divisée par 10 avec la gestion distribuée
Autre optimisation réalisée : l'amélioration du système de révision de source décentralisée de Mercurial. Ce travail est notamment passé par la réduction du volume de données lors des opérations de clonage ou de récupération - en se limitant à la dernières versions des fichiers (à la manière des processus de CVS et Subversion), et les logs de commit correspondants. "Si un élément est manquant ou requis, il pourra être téléchargé par le développeur depuis le serveur central Mercurial", note Facebook.
Le principal bénéfice d'un système de contrôle de source distribué est sa capacité à travailler sans avoir recours au serveur. Avec l'extension développée par Facebook (remotefilelog), les révisions de fichier nécessaires aux commits locaux sont mises en cache pour permettre de travailler sans avoir accès au serveur. Enfin, Facebook a recours à sa distribution memcache en frontal de son serveur Mercurial, ce qui permet de bénéficier d'une solution de back-up immédiat en cas de chute de la plate-forme. "Finalement, notre extension de log de fichier à distance permet de passer la plupart du trafic des requêtes sur memcache, ce qui divise par 10 la charge réseau du serveur Mercurial", conclut Durham Goode.