Pourquoi Facebook (Meta) a-t-il dit "non" à Git ? Une histoire de scaling, de communauté et de monorepos géants
Pourquoi Facebook (Meta) a-t-il dit "non" à Git ? Une histoire de scaling, de communauté et de monorepos géants
Dans le monde du développement logiciel, Git est omniprésent. C'est l'outil par défaut pour des millions de développeurs et de projets, une évidence presque "aussi courante que l'eau", comme le souligne l'auteur de notre source. On le perçoit comme la seule solution viable pour gérer le code. Alors imaginez la surprise de découvrir que Facebook (aujourd'hui Meta), l'une des plus grandes entreprises technologiques du monde, n'utilise pas Git comme système de contrôle de version principal pour ses immenses monorepos.
C'est une histoire fascinante qui met en lumière des défis d'ingénierie à une échelle colossale, les limites d'outils populaires, et l'importance cruciale des facteurs humains dans les décisions technologiques. Plongeons dans les raisons pour lesquelles Meta a choisi un chemin différent.
L'étonnante absence de Git chez Meta
Pour beaucoup, l'idée que Facebook ne tourne pas sous Git est contre-intuitive. L'auteur, dont l'expérience personnelle des systèmes de contrôle de version a commencé avec SVN avant l'explosion de Git, confesse sa propre surprise : "Throughout my life a git was common as water it was so common in fact that I assumed it was the only viable tool for creating and managing code changes". Il raconte comment les ingénieurs de Facebook qu'il a rencontrés étaient "deeply trained on material patterns and Facebook stack diffs workflow" plutôt que sur Git.
Historiquement, même Google, dont l'ingénierie "predates git by over 5 years," utilise son propre système interne. Mais pour Facebook, c'était une décision plus active et récente.
Le mythe de la complexité de Git (et pourquoi ce n'était pas la raison principale)
Avant d'aborder les vraies raisons, il est intéressant de noter que la "difficulté" perçue de Git n'était pas le moteur de cette décision. L'auteur lui-même s'interroge : "I've never understood this kind of commenting get is so confusing how is G confusing like what about git is confusing". Il attribue souvent cette confusion à un manque d'apprentissage fondamental, suggérant que "most of you have just never taking taken the two hours of time it takes to learn get well enough to not be confused by any of it."
Non, la raison du virage de Facebook était bien plus profonde et technique.
Le cauchemar du scaling en 2012 : Quand Git a atteint ses limites
Le véritable point de rupture s'est produit autour de 2012. À cette époque, la base de code de Facebook était déjà "many times larger than even the Linux kernel" (qui comptait 17 millions de lignes et 44 000 fichiers). Avec une croissance exponentielle, Git a commencé à montrer des signes de faiblesse significatifs pour les opérations sur un monorepo aussi gigantesque.
Le goulot d'étranglement clé ? Le processus de "statting" (vérification de l'état) de tous les fichiers. "G examines every file and naturally becomes slower and slower as the number of files increase." Les opérations Git de base, loin d'être "crippling slow," étaient suffisamment lentes pour justifier une enquête approfondie. Les simulations étaient "horrifying," montrant que de simples commandes Git pourraient prendre "over 45 minutes to complete" à mesure que la base de code continuait de croître. C'était intenable pour des milliers d'ingénieurs.
L'appel à l'aide et la réponse surprenante des mainteneurs de Git
Face à ces défis, l'équipe de Facebook a fait ce que beaucoup d'entreprises technologiques auraient fait : elle a contacté les mainteneurs de Git. Leur objectif était de collaborer pour étendre Git et mieux prendre en charge les grands monorepos.
Cependant, la réponse a été inattendue et, selon l'auteur, "wasn't cooperative." Les mainteneurs de Git "pushed back on improving performance and instead recommended that Facebook shared the uh Shard their monor repo" (diviser leur monorepo en plusieurs dépôts).
Cette suggestion, bien que techniquement possible, était un "non-starter" pour Facebook. Ils avaient investi massivement dans un workflow de monorepo et la complexité d'une telle fragmentation aurait été énorme. Plus surprenant encore, Facebook s'attendait à ce que leur offre de "free open source labor by a major tech company is well received," une opportunité d'améliorer un projet open source largement utilisé. Le manque de coopération a été un facteur décisif.
Mercurial : L'alternative inattendue et son architecture propre
Face aux limitations de Git et au manque de soutien pour les monorepos massifs, Facebook a exploré des alternatives. En 2012, les options étaient "scarce". Perforce a été écarté en raison de défauts architecturaux perçus. C'est là que Mercurial est entré en scène.
Mercurial avait des performances "similar to git," mais possédait une architecture bien plus propre. Alors que Git était une "complex web of bash and C code," Mercurial était "engineered in Python using object-oriented code patterns and was designed to be extensible." Cette extensibilité était cruciale.
L'équipe a décidé d'assister à un hackathon Mercurial à Amsterdam. Ce qu'ils ont découvert n'était pas seulement un système flexible, mais aussi "a community of maintainers who were impressively welcoming to aggressive changes by the Facebook team." C'était le contraste parfait avec leur expérience précédente.
La migration interne : Une masterclass en gestion du changement
Convaincre l'ensemble de l'organisation d'ingénierie de migrer de Git vers Mercurial était une tâche "intimidating." Les ingénieurs peuvent être "extremely sensitive about tooling changes." Pourtant, ce qui a suivi "sounds like a masterclass in internal Dev tools migrations."
L'équipe a méthodiquement :
- Socialisé l'idée : Communiquer la nécessité et les avantages.
- Documenté les workflows : S'assurer que chacun savait comment utiliser le nouvel outil.
- Écouté les préoccupations : Permettre aux développeurs d'exprimer leurs doutes.
- Basculé en force : Couper le cordon avec Git une fois que le terrain était prêt.
Le succès de cette migration massive est également attribué, avec une pointe d'ironie, au fait que peu d'ingénieurs de Facebook connaissaient Git en profondeur. Comme l'auteur le note, "it's not even a big deal" de changer d'outil si les ingénieurs ne sont pas attachés à des subtilités spécifiques de Git.
L'héritage de la décision de Facebook : Stack Diffs et un Mercurial amélioré
La décision de Facebook n'a pas été sans conséquences pour l'écosystème open source :
- Mercurial amélioré : Facebook a "contributed performance improvements to Mercurial making it the best option for large monor repos."
- Les "Stack Diffs" : S'appuyant sur les concepts de Mercurial, Facebook a créé un workflow innovant de revue de code appelé "stack diffs" (diffs empilés). Cela a "unlocking novel code review parall parallelization" et a révolutionné leur processus de développement. Des ex-ingénieurs de Facebook ont exporté ce workflow vers d'autres entreprises, créant un "small but vocal Cult of Stack diff Enthusiast," inspirant même l'auteur à créer des outils comme Graphite.
Le facteur humain et l'évolution constante de la technologie
En fin de compte, l'histoire de Facebook et de Git est un rappel poignant que "so many of History's key technical decisions are human driven not technology driven." La réceptivité d'une communauté, l'adaptabilité d'une équipe et la capacité à collaborer peuvent l'emporter sur des avantages techniques perçus.
Il est également crucial de noter que le paysage a évolué. "A decade later GI has made significant improvements to support monor repos... today get now with some knowledge of how to do it operates well with really really large repos now." Git a progressé, et il est possible qu'il puisse aujourd'hui gérer les besoins de Facebook.
L'histoire de Facebook est celle d'une entreprise qui a dû s'adapter à une croissance fulgurante. Face aux limites de performance d'un outil pourtant dominant, et à une communauté qui n'était pas prête à soutenir ses besoins spécifiques à l'époque, ils ont fait un choix pragmatique. Ce n'était pas un rejet de Git en soi, mais une réponse à un problème de scaling unique, résolue avec une solution innovante, et un témoignage du pouvoir des décisions humaines dans l'ingénierie à grande échelle.