Comment Microsoft Office a migré de Source Depot vers Git

• Microsoft Office a longtemps utilisé Source Depot, son système interne de gestion de code source, avant de mener une migration à grande échelle vers Git afin d’améliorer l’expérience développeur et de favoriser l’innovation technique
• Source Depot, avec son fonctionnement centralisé, ses branches lentes et ses workflows peu pratiques, limitait la productivité, et le passage à Git a nécessité le travail de centaines d’ingénieurs sur plusieurs années
• La migration a impliqué de surmonter d’importants défis techniques et organisationnels, notamment via le développement de nouvelles technologies comme VFS for Git, le portage de l’infrastructure existante de build/test et l’exploitation parallèle des deux systèmes
• Pour réussir cette transition, l’équipe a mis l’accent sur une approche collaborative et centrée sur l’humain, avec un système de communication reposant sur des "champions", une transparence assumée, une formation pragmatique et une stratégie de rollback immédiat
• Après la migration, les résultats ont été positifs : réduction du temps d’onboarding, préférence accrue pour Git (89 %) et gains de productivité, avec à la clé plusieurs enseignements majeurs sur les grands changements techniques

---

De Source Depot à Git : retour d’expérience sur la migration à grande échelle de Microsoft Office

Un nouveau défi : maximiser la productivité des développeurs

• Améliorer la productivité des développeurs relève du "Multiplier work", dont la valeur augmente avec la taille de l’organisation
• Le projet de migration de Microsoft Office de Source Depot vers Git en a été un exemple représentatif
• Il ne s’agissait pas d’un simple changement d’outil, mais d’un vaste projet impliquant des centaines d’ingénieurs, des systèmes complexes et une exécution sur une longue période

Source Depot : la gestion de code source à l’époque

• Au début des années 2000, Microsoft exploitait Source Depot, son propre système de gestion de versions basé sur la technologie Perforce
• Source Depot souffrait de branches lentes, d’une architecture centralisée, de temps de checkout très longs et d’un mode de fusion peu pratique (Reverse/Forward Integrate), ce qui limitait l’efficacité du travail
• L’ensemble était fortement couplé à l’infrastructure de développement (build, release, workflow), ce qui rendait un simple remplacement impossible
• La transition de Microsoft Office vers Git a nécessité plusieurs années et les efforts de centaines d’ingénieurs

En commençant par OneNote : le début de la migration

• Au sein de l’organisation d’ingénierie Office, le coût de maintenance et de patch de Source Depot ainsi que le besoin de technologies « compétitives » ont conduit à décider une migration massive vers Git
• La suite Office suivait des calendriers de développement différents selon les cycles de publication (plusieurs mois, semestriel, mensuel, Insider), ce qui a imposé une coexistence prolongée de Source Depot et Git
• La cohérence de la gestion de versions d’Office, la validation des builds et le portage de l’infrastructure de test legacy sont devenus des chantiers essentiels

L’échelle d’Office et la stratégie de communication

• Office était alors une organisation gigantesque comptant 4 000 ingénieurs collaborant ensemble
• Un 'Developer Satisfaction Champion' a été désigné dans chaque équipe, et un modèle hub-and-spoke a été mis en place pour assurer une structure fluide de feedback et de communication entre les équipes
• L’auteur, champion pour OneNote, a joué un rôle clé sur le terrain pendant cette migration de grande ampleur

VFS for Git : dépasser les limites d’une base de code gigantesque

• Une seule commande git clone nécessitait plus de 200 Go, un problème résolu grâce à Virtual File System for Git (VFS for Git), développé conjointement avec GitHub
• VFS for Git ne récupérait que les fichiers réellement utilisés, permettant de dépasser les limites du Git standard
• En collaboration avec Microsoft Windows, l’équipe a ainsi franchi les limites de l’un des plus grands systèmes de gestion de versions du secteur

Une approche par étapes de la migration

Étape 1 : l’univers parallèle (Parallel Universe)

• Un service de bridge synchronisant Source Depot et Git en temps réel a été mis en place, avec des améliorations itératives pour résoudre les écarts et différences de modèle entre les deux systèmes (structure des branches, changelist, etc.)
• Le processus branche principale/branche privée d’Office - synchronisation - build a été exploité sous la forme d’un système automatisé 24/7
• Ce n’est qu’au troisième essai qu’un système parallèle stable a pu être mis en production

Étape 2 : la validation d’équivalence

• L’ensemble des suites de tests a été exécuté à répétition sur les deux systèmes afin de prouver que les résultats de build étaient parfaitement identiques
• Des différences subtiles liées aux fins de ligne, à la casse ou encore au format des résultats de tests ont été déboguées et corrigées pendant plusieurs mois
• Le résultat "Green across the board" (tests validés sur les deux systèmes) a marqué la fin de la préparation avant le basculement réel

Une approche centrée sur l’humain

Communication multicanal et répétée

• Pour aligner les plannings de plus de 4 000 ingénieurs et de dizaines d’équipes, une structure de communication intensive a été bâtie autour des champions de chaque équipe
• Les annonces importantes étaient répétées au moins trois fois (email, Teams, wiki, réunions, etc.) afin de limiter toute confusion
• En cas de problème, une communication immédiate et transparente permettait de conserver la confiance

Formation à Git et adaptation

• Pour les ingénieurs habitués à Source Depot depuis dix ans, un environnement de formation pratique ainsi qu’un guide des commandes de transition ont été mis en place pour accompagner un apprentissage progressif
• Une vidéothèque orientée usage concret a permis de proposer un apprentissage fondé sur des scénarios réels
• Au-delà de la réduction de l’anxiété et du renforcement des compétences, l’objectif était d’aider à l’adaptation aux workflows existants

Stratégie de rollback et garde-fous

• Lors du basculement réel, un "bouton rouge" a été confié au Director afin de permettre un rollback immédiat à tout moment en cas de problème grave
• Une partie de l’historique de Source Depot a été conservée pendant longtemps, garantissant la préservation de l’historique de développement existant

Résultats et principaux acquis

• Après la migration, on a observé des gains de productivité : temps d’onboarding réduit de 50 %, préférence pour Git mesurée à 89 %, amélioration des performances de build, meilleure efficacité des code reviews et hausse de la collaboration
• Les ingénieurs ont également apprécié l’acquisition de compétences transférables dans l’industrie
• La capacité à rendre les nouveaux arrivants opérationnels plus rapidement s’est elle aussi renforcée

Principaux enseignements d’une migration à grande échelle

• Réussir exige d’investir bien davantage que prévu dans la communication centrée sur les personnes, et pas seulement dans les aspects techniques
• Il faut mettre l’accent sur la construction d’un système parallèle, la démonstration d’une équivalence parfaite, la conception d’un rollback solide dès le départ et le rôle des personnes clés (champions)
• Mesurer aussi des indicateurs qualitatifs comme la satisfaction est indispensable, et la stabilité organisationnelle ainsi que le sentiment de sécurité psychologique sont cruciaux pendant le changement
• La véritable nature d’un changement à grande échelle réside dans une gestion du changement souple et structurée à l’échelle de toute l’organisation

Conclusion et applications futures

• La migration d’Office vers Git a été un projet historique, préparé pendant des années puis exécuté sur plusieurs mois
• Elle reste au final un cas exemplaire de transformation organisationnelle menée avec succès tout en garantissant l’interconnexion du travail de milliers de personnes
• Dans d’autres transformations majeures — migration vers le cloud, décomposition d’une architecture monolithique, mise à niveau d’un framework — les mêmes principes peuvent s’appliquer : validation en parallèle, communication répétée, conception d’un rollback rapide
• Les détails techniques (infrastructure de build, enjeux offline/contractuels, etc.) n’ont pas été abordés ici, mais la leçon essentielle reste l’importance de l’approche stratégique et organisationnelle dans les grands changements techniques

[ndrgrd]

Si vous manipulez beaucoup de fichiers binaires, Git n’est peut-être pas adapté, mais pour un dépôt centré sur le code, Git semble largement suffisant.

[rtyu1120]

Cela a sans doute aussi été un grand changement en interne chez MS, mais grâce à cela, le fait que des fonctionnalités comme partial clone, sparse checkout ou des outils comme Scalar aient aussi été publiés et rendus utilisables à l’extérieur me semble être un effet positif, haha.

[GN⁺]

Commentaire Hacker News

• C’est toujours un plaisir de lire une vieille histoire racontée avec un regard neuf. L’auteur de l’article mentionne qu’« il a fallu plusieurs heures pour rapatrier l’ensemble du dépôt Office », mais passe pratiquement sous silence le fait qu’avec git, ce genre d’opération était presque impossible sans un nouveau système de fichiers comme VFS. Avec Perforce, les utilisateurs pouvaient ne récupérer que les parties nécessaires, donc on peut supposer que la plupart des utilisateurs de Source Depot ne téléchargeaient pas l’intégralité d’Office à chaque fois, mais seulement ce dont ils avaient besoin. VFS a réduit cet écart en permettant à git de ne télécharger que les objets nécessaires. Perforce/Source Depot était un VCS centralisé qui constituait un excellent choix à l’époque, mais on a l’impression que les temps ont changé.
  • Il est précisé que, même avec Perforce, certaines entreprises ont développé leur propre technologie pour ne récupérer les fichiers qu’au moment où ils deviennent nécessaires, à la manière de VFS. C’est particulièrement important dans le développement de jeux, où l’on stocke de gros assets binaires en plus des fichiers texte. J’ai l’impression que cela repose sur les mêmes bases que la technologie utilisée par le programme de lecteur distant intégré à Windows. Personnellement, je voudrais toujours un VCS côté serveur qui stocke tout le code de l’entreprise sans exiger une copie locale de tout l’historique. Mais git est déjà largement suffisant pour une collaboration ponctuelle entre plusieurs machines, donc je n’ai pas encore ressenti le besoin de mettre en place un serveur central et toute une pipeline CI/CD. J’apprécie énormément dans git des workflows comme stash, le stage par hunk, le rebase interactif, etc.
  • Mon entreprise utilise encore Perforce, et c’est regrettable de voir que plus personne ne l’aime vraiment. J’ai vu de mes propres yeux l’éclat disparaître du regard des nouveaux arrivants au moment où on leur dit : « Ici, on n’utilise pas git. »
  • VFS ne remplace pas totalement Perforce. En pratique, la plupart des studios AAA utilisent encore Perforce. Il faut pouvoir verrouiller les fichiers d’assets pour éviter que deux personnes les modifient en même temps dans des situations impossibles à fusionner, et c’est indispensable pour éviter de perdre du temps en jetant le travail d’un artiste.
  • Franchement, je me demande encore pourquoi git ne propose toujours pas un moyen de ne faire un checkout sélectif que sur certaines parties de l’arbre du dépôt. J’ai l’impression qu’on pourrait l’étendre assez facilement en ajoutant un service intermédiaire capable de comprendre les fichiers d’objets, entre autres.
• Lors d’un stage chez Microsoft en 2016, j’ai passé presque une semaine sur une fonctionnalité sans même savoir ce qu’était Source Depot, en créant un relecteur de code automatique qui le prenait en charge (https://austinhenley.com/blog/featurestheywanted.html). À l’époque aussi, beaucoup de développeurs utilisaient encore Source Depot. Je me demande si tout a maintenant été migré vers git.
  • CodeFlow me manque encore tous les jours. C’était vraiment un super outil.
  • Il y a encore beaucoup de domaines où Source Depot est activement utilisé. Les commandes Source Depot et la configuration de l’environnement me mettent toujours un peu sous tension.
  • Aujourd’hui, la majeure partie de mon travail quotidien se fait désormais avec git.
• Ayant moi-même utilisé vss (Visual SourceSafe) dans les années 90, je suis surpris que l’article n’en parle même pas. Visual SourceSafe était un protocole de gestion de versions développé en interne par Microsoft, ce qui le distinguait de Source Depot, qui était une version sous licence de Perforce.
  • VSS (Visual SourceSafe) venait du rachat de One Tree Software à Raleigh, et le produit a été renommé de « SourceSafe » à « Visual SourceSafe » puis distribué avec Visual C, Visual Basic, etc. Avant cela, Microsoft vendait un produit de gestion de versions appelé « Microsoft Delta », cher, de mauvaise qualité, et même pas pris en charge sur NT. Parmi les personnes arrivées avec le rachat de One Tree figurait Brian Harry, qui a ensuite dirigé Team Foundation Version Control (TFS). En utilisant SQL Server comme dépôt, TFS apportait une nette amélioration en administration et en fiabilité par rapport à VSS. Brian Harry semble aujourd’hui à la retraite, et son blog n’est plus mis à jour. Un souvenir marquant de VSS à l’époque, c’est qu’il utilisait SMB pour gérer les verrous de fichiers réseau, ce qui le rendait très vulnérable aux erreurs réseau fréquentes et entraînait souvent des corruptions de dépôt. On planifiait donc chaque nuit à l’aube un job batch de réparation pour remettre automatiquement le dépôt en état, afin qu’il soit utilisable le matin.
  • D’après mon expérience de VSS dans les années 90, c’était presque un cauchemar dès qu’on travaillait en équipe, et si je me souviens bien, Microsoft lui-même ne l’utilisait pratiquement pas en interne.
  • J’utilisais VSS en solo dans les années 90, et à l’époque ça me paraissait révolutionnaire. J’ai découvert d’autres VCS plus tard en école doctorale, comme RCS et CVS. Quand je suis entré chez Microsoft en 2004, quelqu’un m’a expliqué que VSS n’était pas sûr et se corrompait facilement. Je ne sais pas si c’était vrai, mais en tout cas, dans l’entreprise, ce n’était même pas une option.
• J’ai fait partie de l’équipe lors de la migration de Microsoft de XNS vers TCP/IP. Ce n’était finalement pas si compliqué que ça, mais on en a tiré des leçons similaires. En revanche, passer de MSMAIL à Exchange, ça, c’était vraiment difficile.
  • J’ai déjà vu autrefois un cadre de plaque avec l’inscription « Exchange: The Most Feared and Loathed Team in Microsoft », et je me demande si cela venait de cette époque. C’était il y a vingt ans, donc je ne me souviens plus de la formulation exacte.
• La phrase « Authenticity mattered more than production value » me parle vraiment. En tant qu’ancien de Microsoft ayant travaillé sur une petite ligne de produits qui n’a commencé à passer de Source Depot à Git qu’au tout dernier moment, juste avant mon départ en 2015, je comprends parfaitement l’énorme quantité d’efforts qu’un tel changement a dû demander. C’est une réalisation impressionnante.
  • Moi aussi, j’ai du mal à croire qu’on ait vraiment traversé tout ça. Merci.
• Quand on regarde la situation à laquelle Microsoft faisait face au début des années 2000, Windows devenait extrêmement complexe et des millions de lignes de code avaient besoin d’un contrôle de version, alors que git n’existait pas encore et que SVN commençait à peine à émerger. Je me demande si Microsoft a sérieusement envisagé des produits commerciaux comme BitKeeper, développé en 1998 et rendu public en 2000. À l’époque, les systèmes centralisés comme Perforce dominaient probablement, et une approche distribuée comme celle de BitKeeper pouvait paraître étrangère ou manquer de références établies.
  • À l’époque, il y avait aussi VSS (Visual SourceSafe), puis plus tard TFVC.
• Merci aux leads de développement qui ont levé pour moi, ingénieur débutant, le mystère de Source Depot. Comprendre réellement sa structure a été une vraie révélation. Comme je ne dépendais que de WinCE et d’IE, mon clone ne prenait que 20 minutes, pas plusieurs jours, et j’en étais bien content. J’ai oublié le nom des personnes qui m’avaient aidé, mais leur volonté d’aider un nouveau à démarrer facilement est quelque chose que je continue moi-même à transmettre dans mon équipe.
• La plupart des gens se souviennent de l’adoption de git comme d’une victoire technique, mais la vraie innovation a surtout été de permettre à chaque développeur de contrôler lui-même son workflow. Plus besoin d’attendre la fenêtre de synchronisation, ni de demander à un lead l’autorisation d’accéder à une branche. Tout le monde peut désormais avancer librement et rapidement sans se bloquer mutuellement. J’ai l’impression que ce changement a eu un impact bien plus fort sur l’ambiance que sur les tableaux de bord de productivité. Git n’a pas seulement changé l’outil, il a aussi transformé la confiance dans la boucle de développement.
• Je me demande à quel moment Microsoft a réellement abandonné Visual SourceSafe en interne. Ils auraient dû l’arrêter plus tôt, ne serait-ce que pour éviter qu’il continue d’être utilisé à l’extérieur.
  • Je pense que la plupart des équipes n’utilisaient pas réellement VSS. Quand je travaillais chez Microsoft, notre équipe utilisait Source Depot. J’ai aussi connu TFS à l’époque, que je n’aimais pas beaucoup, mais après avoir utilisé Source Depot, TFS finissait presque par me manquer.
  • Je me demande si VSS a vraiment été utilisé de manière importante en interne chez Microsoft. S’ils l’avaient réellement utilisé, ils n’auraient probablement pas sorti un produit dans un état aussi bâclé. TFS restait une expérience difficile à comprendre, en interne comme en externe, et ce n’était pas fameux.
  • Ça devait être vers 2000. Le seul projet que je sache l’avoir utilisé était .NET, et même là, il était déjà en cours de migration vers Source Depot.
  • Réaction de quelqu’un qui ne savait même pas que Microsoft SourceSafe existait.
• Je ne comprends pas bien cette histoire selon laquelle le shallow clone de OneNote faisait 200GB.
  • En réalité, il ne s’agissait pas de OneNote, mais du shallow clone de l’ensemble d’Office.
  • Il y avait probablement des vidéos ou de gros fichiers binaires dedans.