Wie Microsoft Office von Source Depot zu Git migrierte

• Microsoft Office nutzte über lange Zeit das interne Quellcodeverwaltungssystem Source Depot und führte dann zur Verbesserung der Developer Experience und für technische Innovationen eine groß angelegte Migration zu Git durch
• Source Depot war durch zentrale Architektur, langsames Branching und umständliche Workflows in der Produktivität begrenzt; der Umstieg auf Git erforderte die Arbeit von Hunderten von Ingenieuren über mehrere Jahre
• Im Verlauf der Migration wurden große technische und organisatorische Herausforderungen bewältigt, darunter die Entwicklung neuer Technologien wie VFS for Git, die Portierung bestehender Build-/Test-Infrastruktur und der Parallelbetrieb beider Systeme
• Für eine erfolgreiche Umstellung wurden ein auf „Champions“ basierendes Kommunikationsmodell, radikale Transparenz, praxisnahe Schulungen und eine sofortige Rollback-Strategie als kollaborativer und menschenzentrierter Ansatz hervorgehoben
• Nach der Migration zeigten sich positive Ergebnisse wie kürzere Onboarding-Zeiten, eine höhere Git-Präferenz (89 %) und gesteigerte Produktivität; zugleich blieben wichtige Lehren für große technische Veränderungen zurück

---

Von Source Depot zu Git: Erfahrungen aus der groß angelegten Migration bei Microsoft Office

Eine neue Herausforderung: Entwicklerproduktivität maximieren

• Die Steigerung der Entwicklerproduktivität ist „Multiplier work“, deren Wert in großen Organisationen besonders hoch ist
• Ein repräsentatives Beispiel dafür war das Projekt zur Migration von Microsoft Office von Source Depot zu Git
• Dabei handelte es sich nicht um einen einfachen Toolwechsel, sondern um ein Großprojekt über lange Zeit mit Hunderten von Ingenieuren und komplexen Systemen

Source Depot: Quellcodeverwaltung aus jener Zeit

• Anfang der 2000er betrieb Microsoft mit Source Depot ein eigenes Versionsverwaltungssystem auf Basis von Perforce-Technologie
• Source Depot hatte Grenzen bei der Arbeitseffizienz durch langsames Branching, Zentralisierung, lange Code-Checkout-Zeiten und umständliche Merge-Verfahren (Reverse/Forward Integrate)
• Es war stark mit der gesamten Entwicklungsinfrastruktur (Build, Release, Workflow) gekoppelt, sodass ein einfacher Austausch strukturell nicht möglich war
• Der Git-Umstieg von Microsoft Office erforderte mehrere Jahre und die Arbeit von Hunderten von Ingenieuren

Beginn mit OneNote: Der Start der Migration

• In der Office-Engineering-Organisation fiel die Entscheidung für einen umfassenden Git-Umstieg aufgrund der Kosten für Wartung und Patches von Source Depot sowie der Anforderung nach „wettbewerbsfähiger Technologie“
• Da die Produkte der Office-Suite je nach Release-Zyklus (mehrere Monate, halbjährlich, monatlich, Insider) unterschiedliche Entwicklungspläne hatten, war ein langfristiger Parallelbetrieb von Source Depot und Git nötig
• Zentrale Aufgaben waren die Sicherung konsistenter Versionsverwaltung in Office, die Build-Validierung und die Portierung der Legacy-Testinfrastruktur

Die Größe von Office und die Kommunikationsstrategie

• Office war damals eine extrem große Organisation, in der 4.000 Ingenieure zusammenarbeiteten
• Für jedes Team wurde ein 'Developer Satisfaction Champion' benannt; über ein Hub-and-Spoke-Modell zwischen den Teams wurde eine reibungslose Feedback- und Kommunikationsstruktur aufgebaut
• Der Autor war Champion für OneNote und übernahm damit eine Schlüsselrolle direkt im Zentrum der groß angelegten Migration

VFS for Git: Die Grenzen extrem großer Codebasen überwinden

• Da bereits ein einziges git clone mehr als 200 GB erforderte, wurde das Problem gemeinsam mit GitHub durch Virtual File System for Git (VFS for Git) gelöst
• VFS for Git überwand die Grenzen von Standard-Git, indem nur tatsächlich benötigte Dateien geladen wurden
• In Zusammenarbeit mit Microsoft Windows war dies eine Erfahrung an der Grenze dessen, was bei einigen der größten Versionsverwaltungssysteme der Branche möglich war

Der stufenweise Migrationsansatz

Phase 1: Paralleles Universum (Parallel Universe)

• Es wurde ein Bridge-Service aufgebaut, der Source Depot und Git in Echtzeit synchronisierte; Probleme durch Inkonsistenzen und Modellunterschiede beider Systeme (Branch-Struktur, Changelists usw.) wurden wiederholt verbessert
• Der Ablauf aus Office-Main-/Private-Branches, Synchronisierung und Build wurde als 24/7-Automatisierungssystem betrieben
• Erst nach drei Anläufen wurde ein stabil funktionierendes paralleles System umgesetzt

Phase 2: Gleichwertigkeitsnachweis

• Sämtliche Test-Suites wurden wiederholt auf beiden Systemen ausgeführt, um zu belegen, dass die Build-Ergebnisse vollständig identisch waren
• Feine Unterschiede bei Zeilenumbrüchen, Groß-/Kleinschreibung und Testresultat-Formaten wurden über Monate hinweg debuggt und beseitigt
• Mit dem Ergebnis „Green across the board“ (Tests auf beiden Systemen erfolgreich) war die Vorbereitung für den eigentlichen Umstieg abgeschlossen

Ein menschenzentrierter Ansatz

Mehrkanalige, wiederholte Kommunikation

• Um die Zeitpläne von mehr als 4.000 Ingenieuren und Dutzenden Teams aufeinander abzustimmen, wurde mit Champions pro Team und einer intensiven Kommunikationsstruktur gearbeitet
• Wichtige Ankündigungen wurden mindestens dreimal wiederholt (E-Mail, Teams, Wiki, Meetings usw.), um Verwirrung zu minimieren
• Bei Problemen wurde durch sofortige und transparente Offenlegung von Informationen Vertrauen geschaffen

Schulung und Eingewöhnung für Git

• Für Ingenieure, die zehn Jahre lang mit Source Depot gearbeitet hatten, wurde ein stufenweises Lernsystem mit praxisnahen Übungsumgebungen und Leitfäden für Umstiegsbefehle bereitgestellt
• Über eine videobasierte Bibliothek mit Fokus auf reale Arbeitssituationen wurde szenariobasiertes Lernen ermöglicht
• Das diente nicht nur dem Abbau von Unsicherheit und dem Kompetenzaufbau, sondern auch der Anpassung an bestehende Workflows

Rollback-Strategie und Sicherheitsmechanismen

• Beim eigentlichen Umstieg erhielt der Director einen „roten Knopf“, mit dem bei schwerwiegenden Problemen jederzeit sofort ein Rollback möglich war
• Teile der bisherigen Historie aus Source Depot wurden über lange Zeit aufbewahrt, sodass die bestehende Entwicklungshistorie sicher erhalten blieb

Ergebnisse und wichtigste Erfolge

• Nach der Umstellung zeigte sich eine um 50 % kürzere Onboarding-Zeit, eine Git-Präferenz von 89 %, verbesserte Build-Performance sowie Produktivitätsgewinne bei Code Reviews und Zusammenarbeit
• Ingenieure bewerteten positiv, dass sie in der Branche übertragbare Fähigkeiten erwerben konnten
• Auch die direkte Einsatzfähigkeit neuer Mitarbeiter stieg

Zentrale Lehren aus einer groß angelegten Migration

• Für den Erfolg muss nicht nur in Technik, sondern weit mehr als erwartet in menschenzentrierte Kommunikation investiert werden
• Entscheidend sind der Aufbau paralleler Systeme, der Nachweis vollständiger Gleichwertigkeit, ein klarer Rollback-Plan von Beginn an und die Hervorhebung von Schlüsselpersonen (Champions)
• Qualitative Kennzahlen wie Zufriedenheit müssen unbedingt mitgemessen werden; organisatorische Stabilität und psychologische Sicherheit sind im Wandel besonders wichtig
• Das Wesen großer Veränderungen liegt in einem flexiblen und systematischen Change-Management über die gesamte Organisation hinweg

Fazit und mögliche Anwendung darüber hinaus

• Die Git-Migration von Office war ein historisches Projekt, das durch jahrelange Vorbereitung und mehrere Monate Umsetzung zustande kam
• Letztlich bleibt es als Beispiel für eine erfolgreich vorangetriebene organisatorische Veränderung bei gleichzeitiger Sicherung der Arbeitszusammenhänge Tausender Menschen bestehen
• Auch bei anderen großen Veränderungen wie Cloud-Migration, der Zerlegung monolithischer Architekturen oder Framework-Upgrades lassen sich Parallelvalidierung, wiederholte Kommunikation und schnell geplantes Rollback gleichermaßen anwenden
• Technische Details (Build-Infrastruktur, Offline-/Vertragsthemen usw.) wurden zwar nicht weiter behandelt, doch die wichtigste Lehre ist der strategische und organisatorische Ansatz für große technische Veränderungen

[ndrgrd]

Wenn man viele Binärdateien verarbeitet, ist Git vielleicht nicht die beste Wahl, aber für codezentrierte Repositories scheint Git völlig auszureichen.

[rtyu1120]

Das war sicher auch intern bei Microsoft eine große Veränderung, aber ich finde es auch positiv, dass dadurch Funktionen wie partial clone und sparse checkout sowie Tools wie Scalar öffentlich verfügbar gemacht wurden und nun auch extern genutzt werden können haha

[GN⁺]

Hacker-News-Kommentare

• Es ist immer wieder schön, solche alten Geschichten in neuer Form erzählt zu bekommen. Der Hinweis ist, dass der Originalartikel zwar erwähnt, es habe mehrere Stunden gedauert, das gesamte Office-Repository zu holen, dabei aber im Grunde auslässt, dass so etwas mit git ohne neue Dateisysteme wie VFS praktisch kaum möglich gewesen wäre. In Perforce konnten Nutzer nur die Teile auschecken, die sie brauchten, daher haben vermutlich auch die meisten Source-Depot-Nutzer nicht jedes Mal die komplette Office-Anwendung geholt, sondern nur die benötigten Bereiche. VFS verringerte diese Lücke, indem es in git nur die benötigten Objekte herunterladen ließ. Perforce/Source Depot war als zentralisiertes VCS damals eine hervorragende Wahl, aber heute wirkt es wie aus einer anderen Zeit.
  • Es wird erklärt, dass es auch für Perforce Firmen gibt, die eine eigene Technik gebaut haben, um Dateien ähnlich wie bei VFS erst bei Bedarf zu holen. Das ist besonders wichtig in der Spieleentwicklung, wenn neben Textdateien auch große binäre Source-Assets gespeichert werden. Ich denke, das hat dieselben Wurzeln wie die Technik, die von in Windows integrierten Remote-Drive-Programmen verwendet wird. Persönlich hätte ich weiterhin gern ein serverbasiertes VCS, das den gesamten Quellcode des Unternehmens speichert, ohne lokal die komplette Historie replizieren zu müssen. Aber git ist für gelegentliche Zusammenarbeit zwischen mehreren Geräten gut genug, sodass ich bisher nicht das Bedürfnis hatte, einen zentralen Server samt CI/CD-Pipeline aufzubauen. Dafür mag ich in git viele verschiedene Workflows sehr, etwa stash, Stage auf Hunk-Ebene und interaktives Rebase.
  • Unsere Firma nutzt immer noch Perforce, und es ist bedauerlich, dass heute offenbar niemand mehr Perforce mag. Ich habe selbst gesehen, wie Neulingen der Glanz in den Augen verschwindet, sobald man ihnen sagt: „Wir verwenden kein git.“
  • VFS ersetzt Perforce nicht vollständig. Es wird betont, dass die meisten AAA-Spielestudios tatsächlich noch immer Perforce verwenden. Man muss Asset-Dateien sperren können, damit nicht zwei Personen gleichzeitig Änderungen vornehmen und eine nicht zusammenführbare Situation entsteht; das ist unverzichtbar, um Zeitverschwendung zu vermeiden, wenn die Arbeit eines Künstlers verworfen werden müsste.
  • Ich frage mich ehrlich, warum git bis heute keine Funktion bietet, nur bestimmte Teile eines Repository-Baums selektiv auszuchecken. Mit einem zwischengeschalteten Dienst, der Objektdateien und Ähnliches versteht, sollte sich das meiner Meinung nach leicht erweitern lassen.
• Während eines Microsoft-Praktikums 2016 habe ich einen automatischen Code-Reviewer gebaut, der Source Depot unterstützte, und fast eine Woche in diese Funktion gesteckt, ohne überhaupt zu wissen, was Source Depot ist (https://austinhenley.com/blog/featurestheywanted.html). Damals nutzten es noch immer viele Entwickler. Ich frage mich, ob inzwischen wirklich alle zu git migriert sind.
  • Ich vermisse CodeFlow jeden Tag. Es war wirklich ein großartiges Tool.
  • Es heißt, dass es noch immer viele Bereiche gibt, in denen Source Depot aktiv genutzt wird. Die Source-Depot-Befehle und Umgebungseinstellungen versetzen mich immer in Anspannung.
  • Den Großteil meiner täglichen Arbeit erledige ich inzwischen in git.
• Als jemand, der in den 90ern selbst vss (Visual SourceSafe) benutzt hat, überrascht es mich, dass dieser Artikel es nicht einmal erwähnt. Visual SourceSafe war Microsofts eigenes Protokoll für Quellversionsverwaltung, während Source Depot im Unterschied dazu von Perforce lizenziert und genutzt wurde.
  • VSS (Visual SourceSafe) war ein Produkt, das durch die Übernahme von One Tree Software aus Raleigh ins Haus kam; der Produktname wurde von „SourceSafe“ in „Visual SourceSafe“ geändert und dann zusammen mit Visual C, Visual Basic und Ähnlichem gebündelt. Davor verkaufte Microsoft ein Versionsverwaltungsprodukt namens „Microsoft Delta“, das teuer war, schlechte Qualität hatte und unter NT überhaupt nicht unterstützt wurde. Zu den Leuten, die über die One-Tree-Übernahme kamen, gehörte Brian Harry, der später Team Foundation Version Control (TFS) leitete. Mit SQL Server als Repository war es deutlich besser administrierbar und zuverlässiger als VSS. Brian Harry scheint inzwischen im Ruhestand zu sein, und sein Blog wird offenbar nicht mehr aktualisiert. Eine Erinnerung an VSS ist, dass Netzwerk-Dateisperren über SMB abgewickelt wurden und deshalb anfällig für häufige Netzwerkfehler waren; dabei wurde das Repository oft beschädigt. Deshalb musste man einen Batch-Job einrichten, der jeden Morgen früh Reparaturen ausführte, damit das System morgens wieder nutzbar war.
  • Meiner Erfahrung mit VSS in den 90ern nach war es für Teamarbeit nahezu ein Albtraum, und soweit ich weiß, hat Microsoft es intern auch kaum verwendet.
  • Ich habe VSS in den 90ern genutzt, als ich allein entwickelt habe, und damals fühlte es sich wie eine völlig neue Welt an. Später lernte ich in der Graduiertenschule andere VCS kennen, etwa RCS und CVS. Als ich 2004 bei Microsoft anfing, erklärte mir jemand, VSS sei unsicher und neige leicht zu Beschädigungen. Ob das wirklich stimmt, weiß ich nicht, aber jedenfalls war VSS im Unternehmen überhaupt keine Option.
• Ich war im Team, als Microsoft von XNS auf TCP/IP migrierte. Das war weniger komplex als erwartet, aber die Lehren waren ähnlich. Die Umstellung von MSMAIL auf Exchange war wirklich hart.
  • Ich habe einmal einen Kennzeichenrahmen mit der Aufschrift „Exchange: The Most Feared and Loathed Team in Microsoft“ gesehen und frage mich, ob das auf diese Erfahrungen zurückgeht. Das ist 20 Jahre her, daher erinnere ich mich nicht mehr an die genaue Formulierung.
• „Authenticity mattered more than production value“ hat mich wirklich angesprochen. Als ehemaliger Microsoft-Mitarbeiter, der in einer kleinen Produktlinie arbeitete, die erst kurz vor meinem Weggang 2015 mit dem Wechsel von Source Depot zu Git begann, kann ich vollkommen nachvollziehen, wie viel Aufwand in so etwas steckt. Wirklich eine beeindruckende Leistung.
  • Ich kann selbst kaum glauben, dass wir all diese Prozesse tatsächlich durchlaufen haben. Danke dafür.
• Wenn man sich ansieht, in welcher Lage Microsoft Anfang der 2000er war, wurde Windows enorm komplex und Hunderte Millionen Codezeilen brauchten Versionsverwaltung, während git noch gar nicht existierte und SVN gerade erst aufkam. Ich frage mich, ob Microsoft kommerzielle Produkte wie BitKeeper, das 1998 entwickelt und 2000 veröffentlicht wurde, ernsthaft in Betracht gezogen hat. Vermutlich waren damals zentralisierte Systeme wie Perforce der Mainstream, und verteilte Systeme wie BitKeeper wirkten vielleicht fremdartig oder hatten noch zu wenige bewährte Einsatzbeispiele.
  • Damals gab es auch VSS (Visual SourceSafe) und später dann TFVC.
• Ich bin den Development Leads dankbar, die einem Anfänger wie mir die Geheimnisse von Source Depot erklärt haben. Als ich die Struktur von Source Depot richtig verstand, war das ein echter Augenöffner. Ich hatte Glück, dass ich nur von WinCE und IE abhing und ein Clone deshalb nur 20 Minuten dauerte statt mehrere Tage. Ich habe die Namen der Leute vergessen, die mir geholfen haben, aber ihre Haltung, Neulingen den Einstieg zu erleichtern, führe ich heute in meinem eigenen Team weiter.
• Die meisten erinnern die Einführung von git als technischen Sieg, aber die eigentliche Innovation war, dass einzelne Entwickler ihre Workflows selbst kontrollieren konnten. Man musste nicht mehr auf Sync-Fenster warten und den Lead nicht mehr um Zugriff auf Branches bitten. Plötzlich konnte jeder frei und schnell arbeiten, ohne sich gegenseitig in die Quere zu kommen. Mein starker Eindruck ist, dass dieser Wandel für die Stimmung viel mehr bewirkt hat als jedes Produktivitäts-Dashboard. git war nicht nur ein Tool, sondern hat auch das Vertrauen in die Entwicklungs-Loop verändert.
• Ich frage mich, wann Microsoft intern wirklich von Visual SourceSafe weggekommen ist. Meiner Meinung nach hätte man es früher einstellen sollen, damit es extern nicht noch so lange weiterverwendet wurde.
  • Ich nehme an, die meisten Teams haben VSS in der Praxis nie benutzt. Ich habe bei Microsoft gearbeitet, und unser Team nutzte Source Depot. Ich habe damals auch TFS kennengelernt und mochte es nicht besonders. Trotzdem habe ich nach der Arbeit mit Source Depot am Ende sogar TFS vermisst.
  • Ich bezweifle, dass VSS intern bei Microsoft für Hauptzwecke verwendet wurde. Wenn es dort wirklich ernsthaft intern im Einsatz gewesen wäre, hätte man es wohl kaum in einem so schlampigen Zustand veröffentlicht. TFS war eine Erfahrung, die ich kaum nachvollziehen konnte, intern wie extern, und nicht im positiven Sinn.
  • Es dürfte etwa um das Jahr 2000 gewesen sein. Das einzige Projekt, von dem ich weiß, dass es es nutzte, war .NET, und selbst das war bereits zu Source Depot gewechselt.
  • Eine Reaktion ist, dass man nicht einmal wusste, dass es überhaupt Microsoft SourceSafe gab.
• Ich verstehe die Aussage nicht ganz, dass ein OneNote-Shallow-Clone 200 GB groß sei.
  • Gemeint war wohl nicht OneNote, sondern ein Shallow Clone des gesamten Office.
  • Vermutlich waren Videos oder große Binärdateien enthalten.