Codeverwaltung à la Facebook: Mercurial als Git-Killer?

Redaktion JAXenter

Facebook ist für seine schnellen Entwicklungszyklen und häufigen Deployments bekannt. Aber wie verwalten die Entwickler dort eigentlich die Unmengen an Code, die tagein, tagaus geschrieben werden? In einem gerade veröffentlichten Blogpost lässt sich das kalifornische Social-Media-Unternehmen diesbezüglich in die Karten schauen und gibt Details über seine Arbeit mit dem quelloffenen Repository-System Mercurial preis, die zeigen: In vielen Entwicklercommunities wird Git derzeit zwar als das Nonplusultra gepriesen, wenn es um Versionsverwaltung geht; aber es gibt durchaus Alternativen, die es in puncto Skalierbarkeit und Performance ausstechen – mit etwas Tuning, versteht sich.

Mercurial, maßgeschneidert

Was nicht passt, wird passend gemacht – diese Devise scheint bei Facebook zu gelten, wenn vorhandene Technologien den alles andere als durchschnittlichen Anforderungen nicht genügen. Dann wird auf Basis bewährter Tools und Sprachen kurzerhand eine auf den eigenen Bedarf zugeschnittene neue Technologie eingeführt, um die Produktivität anzukurbeln – ob HipHop Virtual Machine für die Übersetzung von PHP in C++-Code, die Suchengine Presto, die seit November Open Source ist, oder eben Mercurial.

Bereits vor zwei Jahren, so die Entwickler Durham Goode und Siddarth Agarwal, sei abzusehen gewesen, dass die damals verwendeten Technologien – ein Subversion-Server mit Git-Mirror – früher oder später zu einem Produktivitätsengpass führen würden. Dass man es bei einem einzelnen Repository belassen wollte, stand von Anfang an fest. Zu stark und komplex waren die Abhängigkeiten, zu umfassend die Refactorings, die täglich durchgeführt werden, als dass die Codebasis hätte modularer gestaltet werden können.

Alternativen gab es allerdings wenige. Git war den meisten Teammitgliedern vertraut, skalierte jedoch nicht ausreichend. Und so legte das Entwicklerteam selbst Hand an und erweiterte Mercurial. Die Vorteile dieses verteilten Versionskontrollsystems:

  • Es ist Git-ähnlich (entstand zur selben Zeit im selben Umfeld; ebenfalls dezentral/verteilt)
  • Es ist in reinem Python entwickelt und dadurch leicht erweiterbar
  • Es hat eine aktive Community, die dem Facebook-Team unter die Arme greift

Die Entscheidung für Mercurial muss sich für die Entwickler anfangs wie ein Rückschritt angefühlt haben, war das System doch in einigen Bereichen wesentlich langsamer als Git. 500 Patches später war man dem Ziel schon näher gekommen, hatte es aber bei Weitem noch nicht erreicht.

File Monitoring mit Watchman

Einen Engpass stellte den Entwicklern zufolge die Erkennung von Dateiänderungen dar. Sowohl der Git- als auch Perforce-Ansatz, Änderungen aufzuspüren, waren für Facebooks Zwecke zu gering skalierbar bzw. nicht ausreichend nutzerfreundlich. Die Lösung lautete File Monitoring: Mithilfe der Erweiterung hgwatchman, die für jeden frei zugänglich ist, wurde Mercurial mit dem – ebenfalls hauseigenen – Dateiüberwachungssystem Watchman integriert. Im Ergebnis soll der Statusbefehl von Mercurial fünfmal so schnell sein wie der von Git. Wesentliche Performancegewinne will man ebenfalls für andere Befehle wie diff, update und commit verzeichnet haben.

Making History

In Sachen Versionsgeschichte galt es einen Mittelweg zu finden zwischen einem zentralen Versionsverwaltungssystem wie Subversion, das die History auf dem Server belässt und so Speicherplatz spart, und einem dezentralen System wie Mercurial und Git, das eine lokale Kopie auf dem Client erstellt und ihn dadurch unabhängig vom Status des Servers macht. Die eigens entwickelte und ebenfalls Open Source verfügbare remotefilelog-Erweiterung sorgt dafür, dass die clone– und pull-Befehle statt der Gesamtheit an Dateiänderungen lediglich die Metadaten herunterladen. Sie ermöglicht intelligentes Caching, durch das Änderungen auch ohne Server-Zugang vorgenommen werden können. Was nicht bedeutet, dass bei Bedarf nicht auch der Inhalt der Datei geladen werden kann. Hier setzt Facebook auf die bewährte Memcache-Infrastruktur, die zudem für eine gewisse Ausfallsicherheit sorgt.

Die Entwickler räumen allerdings ein, dass diese Lösung von einem verlässlichen Mercurial-Server und einem Netzwerk mit geringen Latenzzeiten ausgeht und daher „not for everyone“ sei. Ein gewisses Risiko scheint man bei Facebook allerdings gern in Kauf zu nehmen – solange dieses durch beträchtliche Performancegewinne aufgewogen wird.

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: