Pourquoi le développeur de Graphite, Greg Foster, s’y est intéressé
- Il a lancé le projet Graphite en s’inspirant des outils internes de Facebook
- Après que d’anciens collègues de Facebook lui ont présenté Mercurial et le workflow de "stacked diffs", il a décidé de l’introduire pour les développeurs GitHub et a finalement créé une CLI qui intègre des idées de Hg dans Git
- Pourquoi Facebook a-t-il adopté Mercurial plutôt que Git et construit un workflow personnalisé par-dessus ?
- Google non plus n’utilise pas Git, mais c’est parce que l’ingénierie de Google avait plus de 5 ans d’avance sur Git
- En revanche, Facebook a été fondé en 2004, à peu près à la même époque que la création de Git, et au moment où Facebook a commencé à étudier sérieusement les outils de contrôle de source, Git était plus populaire que Mercurial
- Alors pourquoi Facebook n’utilise-t-il pas Git ?
- Selon lui, si Facebook avait adopté Git et y avait contribué au début des années 2010, le monde de l’ingénierie serait différent
- Git serait peut-être plus convivial et prendrait en charge nativement les Stacked Changes
- Des entreprises comme Uber et Pinterest, créées par d’anciens employés de Facebook, auraient elles aussi utilisé Git et GitHub comme système de gestion de source au lieu de Mercurial, ce qui aurait produit un écosystème moins fragmenté au cours de la dernière décennie
- Mais Facebook n’est pas resté sur Git (pour son monorepo principal). À la place, l’entreprise a adopté Mercurial pour le contrôle de version et y a progressivement ajouté des outils personnalisés
- Il est tombé sur l’article de Facebook Scaling Mercurial at Facebook
- L’article date d’il y a 10 ans, et après quelques vidéos YouTube, il en a tiré la réponse : "à cause des performances"
- Mais il voulait aller plus loin et entendre le point de vue des décideurs de l’époque ; il a donc interrogé deux ingénieurs qui avaient participé au projet de migration vers Mercurial
- Il a synthétisé ce contenu à partir de conversations informelles avec eux
Pourquoi Facebook a abandonné Git pour migrer vers Mercurial
- Facebook utilisait Git au départ, mais vers 2012, alors que la taille de la base de code augmentait, l’entreprise a commencé à rencontrer des problèmes de performance
- Le processus de
stat des fichiers dans Git devenait un goulot d’étranglement, et l’exécution des commandes Git de base prenait plus de 45 minutes
- Les mainteneurs de Git n’étaient pas coopératifs face aux problèmes de très grand dépôt rencontrés par Facebook et recommandaient plutôt de découper le dépôt
Les alternatives envisagées
- En 2012, il n’existait pas beaucoup d’alternatives à Git ; Facebook a envisagé des solutions closed source comme Perforce, mais il y avait des problèmes techniques
- Mercurial offrait des performances similaires à Git, mais avec une architecture plus propre et une meilleure extensibilité
- L’équipe de Facebook a participé à un hackathon Mercurial et a été impressionnée par l’extensibilité de Mercurial ainsi que par l’ouverture de sa communauté
La migration de toute l’organisation d’ingénierie
- Pour convaincre le reste de l’entreprise, l’équipe de Facebook a fait correspondre les commandes et workflows entre Git et Mercurial, et a pris le temps d’écouter les inquiétudes des développeurs
- La migration a été menée avec prudence, et Facebook a finalement basculé vers Mercurial
- Facebook a contribué à améliorer les performances de Mercurial et a notamment permis la parallélisation des revues de code via les "stacked diffs"
Réflexions de conclusion
- Cette histoire rappelle que "de nombreuses décisions techniques majeures ne sont pas guidées par la technologie, mais par les personnes"
- Facebook a choisi Mercurial non pas parce qu’il était plus performant que Git, mais parce que la collaboration avec les mainteneurs de Mercurial était plus ouverte
- Lorsqu’il a fallu convaincre toute l’organisation d’ingénierie, ce n’est pas parce qu’une technologie était meilleure qu’une autre que cela a compté, mais parce qu’il y avait une "communication réfléchie"
- L’importance de la "communication et de la bienveillance" dans l’univers des outils de développement est mise en avant
2 commentaires
Cela me fait penser à cette phrase qu’une connaissance m’a dite : « Pour convaincre le client, il faut devenir son gratte-dos. »
Pas besoin d’être trop tranchant, ni trop rapide, ni trop pratique, ni trop cher ; si on peut simplement gratter exactement là où il le souhaite, alors c’est ça, le service que le client veut, haha.
Git a été créé par Linus Torvalds pour gérer le code source de Linux, donc je pense qu’il y avait forcément certains points sur lesquels aucun compromis n’était possible.
L’idée générale de la conclusion donne presque l’impression que Git serait mauvais parce qu’il n’a pas écouté les exigences de Facebook et n’a pas accordé d’importance à la communication et à la bienveillance, mais à mon avis, c’est simplement que leurs orientations différaient sur plusieurs aspects.
À l’inverse, on peut aussi considérer que Facebook avait la possibilité d’accepter et de mettre en œuvre la division du dépôt recommandée par Git. C’était simplement une forme de bienveillance qu’ils ne voulaient pas.