Dropbox 22.04.2020, 13:45 Uhr

Zur Testbarkeit der neuen Dropbox-Sync-Maschine

Software-Ingenieur Isaac Goldberg schildert in einem Blogbeitrag die Geschichte der Entwicklung der neuen Dropbox-Sync-Maschine, welche die vor zwölf Jahren entstandene klassische Engine abgelöst hat. Insbesondere geht es dabei um die Testbarkeit.
(Quelle: https://dropbox.tech/)
Dropbox hat seine Synchronisationsmaschine vollständig neu geschrieben. Dafür musste die Engine, die Dropbox antreibt und auf Hunderten von Millionen von Benutzerrechnern arbeitet, während des Betriebs ausgetauscht werden. Von Beginn an wusste das Dropbox-Team, dass dieses Vorhaben eine ernsthafte Investition in automatisierte Tests bedeuten würde. Zugleich gab die Teststrategie dem Team die Zuversicht, dass sie während der gesamten Überarbeitung auf dem richtigen Weg waren und heute ermöglicht sie Dropbox, weiterhin neue Funktionen in einem schnellen Release-Zyklus zu entwickeln und auszuliefern.

Testbarkeit

Als das Dropbox-Team mit der Neufassung begann, war eines klar: Um eine robuste Teststrategie zu haben, musste das neue System testbar sein! Die frühzeitige Betonung der Testbarkeit, noch vor der Implementierung der zugehörigen Test-Frameworks, war entscheidend. Aber was bedeutet Testbarkeit überhaupt? Die bisherige Sync Engine Classic war nicht testbar. Außerdem wurden Server-Client-Protokoll und Datenmodell der Classic-Engine für eine einfachere Zeit und ein einfacheres Produkt entwickelt. Damals erlaubte Droppbox noch keine gemeinsame Nutzung, bot keine Kommentare und Anmerkungen und wurde zudem noch nicht von tausenden Unternehmensteams verwendet. Dropbox hat sich in den vergangenen zwölf Jahren, also seit dem das ursprüngliche System entworfen wurde, ziemlich weiterentwickelt. Die Anforderungen haben sich stark verändert.
Das Client-Server-Protokoll von Sync Engine Classic führte oft zu einer Reihe von möglichen Synchronisierungszuständen, die viel zu freizügig waren, als dass wir sie effektiv testen konnten, erklärt Isaac Goldberg in seinem Blogbeitrag, in dem er über die Neufassung der Dropbox-Engine spricht. Zum Beispiel konnte ein Client Metadaten vom Server über eine Datei unter /baz/cat erhalten, bevor er sein übergeordnetes Verzeichnis unter /baz erhielt. Dementsprechend musste die lokale Datenbank (SQLite) des Clients diesen verwaisten Zustand darstellen, und jede Komponente, die Dateisystem-Metadaten verarbeitet, musste diesen Zustand unterstützen. Dies wiederum machte es unmöglich, viele Arten schwerwiegender Inkonsistenzen (zum Beispiel verwaiste Dateien) von einem Client zu unterscheiden, der sich lediglich in einem akzeptablen vorübergehenden Zustand befand.
Wie das Dropbox-Team dieses und viele andere Probleme in den Griff bekommen hat, schildert Goldberg ausführlich in seinem Artikel auf dropbox.Tech.


Das könnte Sie auch interessieren