Launch-Zeitpunkt wählen: Herausforderungen bei Transloadit
Vor ein paar Wochen versammelte sich das Team in einem dieser winzigen Skype-Konferenzfenster, um eine wichtige Frage zu besprechen: Sollten wir Transloadit in seiner aktuellen Version starten?
Nach Wichtigkeit geordnet, waren das die Probleme, vor denen wir zu diesem Zeitpunkt standen:
- Wir steckten auf Node
v0.1.28fest - Wir hatten sehr wenige Unit-Tests
- Das System hatte einige Schwachstellen im Design
Gleichzeitig wussten wir aber, dass das System zu erstaunlichen Dingen fähig ist. Einige unserer Alpha-Tester nutzen es, um große Videos hochzuladen und daraus bis zu 32 Ergebnisdateien zu erzeugen (Wasserzeichen und Thumbnails in verschiedenen Größen), die anschließend zu S3 hochgeladen werden. Das sind mehr als 100 interne Jobs, die wir starten und im Zusammenspiel verwalten, und das alles dank der Großartigkeit von Node.
Mit diesem Gedanken im Hinterkopf entschieden wir uns, es anzugehen und auf der bevorstehenden JSConf zu starten. Bis letzte Woche haben wir fieberhaft daran gearbeitet, dieses Ziel zu erreichen. Wir haben Kreditkartenzahlungen in die Website integriert, einen großartigen Tarif und ein Preismodell entwickelt und unzählige Stunden investiert, um die letzten Bugs aus dem System zu quetschen.
Und dann … flogen uns die Bytes um die Ohren.
Uns war aufgefallen, dass unser Node-Server alle 1 bis 2 Wochen abstürzte, aber wir führten das auf einen eigenen Fehler zurück und dachten sicher nicht, dass daraus ein riesiges Problem werden würde. Genau das geschah dann aber. Beim Testen einiger der intensiveren Assemblies, die zuvor erwähnt wurden, stellten wir fest, dass der Server häufiger abstürzte. Wie sich herausstellt, hat die alte Version, die wir einsetzen, einige gravierende Probleme im Netzwerkcode. Wenn ein solches Problem auftritt, sehen Sie zuletzt Folgendes:
(evcom) recv() Success
Und dann stirbt der Server. Ohne Segfaults oder Details.
Autsch! Ein Jahr harter Feierabendarbeit ging plötzlich in Flammen auf. Nun könnten wir enormen Aufwand betreiben, um diesen Bug aufzuspüren und ihn vielleicht sogar zu beheben. Tatsache ist jedoch, dass wir damit das falsche Problem beheben würden.
Das eigentliche Problem ist, dass wir auf einer alten Node-Version sind. Und der Grund dafür ist, dass wir uns nicht an die Worte von Uncle Bob gehalten haben:
„Professionalität - hat sich der Arzt die Hände gewaschen, haben Sie Ihre Tests geschrieben?“
Hätten wir eine gute Testabdeckung für unseren Code, wäre das Upgrade von Node kein großes Problem. Einige der Designprobleme innerhalb der Anwendung zu refaktorieren, wäre ebenfalls kein großes Problem.
Jetzt tun wir also das, was wir von Anfang an hätten tun sollen: Wir schreiben unsere alte Version
in eine neue, vollständig getestete um, die auf dem kommenden Node 0.2.0
aufbaut. Das wird einige Zeit dauern, aber glücklicherweise können wir viel von der mühsamen
Trial-and-Error-Arbeit wiederverwenden, die wir aus Version 1 gelernt haben.
Wir möchten allen danken, die Version 1 getestet haben, und freuen uns darauf, Sie über Version 2 auf dem Laufenden zu halten.
P.S. Wie sich herausstellte, habe ich es wegen des Vulkans doch nicht zur JSConf geschafft. Wir nehmen das als Zeichen. 😄