Worum es hier geht
Während den letzten Wochen, in denen wir am Release des Netzwerkes gesessen haben, hat uns vermehrt Feedback via Discord erreicht, dass unser Entwicklungsprozess für Nutzer recht intransparent ist - dies möchten wir mit unseren DevBlogs ändern.
Der erste DevBlog soll somit den bisherigen Entwicklungsstand grob darstellen und aufzeigen wieso der Release sich, trotz mutmaßlich 15 Entwicklern, weiterhin verzögert.
Der Anfang
Am Anfang des Lotus Projektes gab es eine "Bewerbungsphase" - Entwickler konnten sich mittels Ticket beim Netzwerk bewerben und wurden relativ schnell entweder abgelehnt oder akzeptiert und einem Channel für Devs hinzugefügt.
Von dort an warteten wir geduldig, bis uns die NDAs erreichten - also unsere Geheimhaltungsvereinbarungen. Diese NDAs sind zwingend erforderlich um teaminterne Informationen und Code zu schützen, konnten also nicht übersprungen oder nachgeholt werden, da sonst das Urheberrecht an neuem Code automatisch beim Urheber, also dem Entwickler, verbleiben würde und jeder Entwickler Lotus zwingen könnte seinen Code wieder zu entfernen - jederzeit und unverzüglich.
Während wir auf die NDAs warteten, wurden mehrere Konzepte für diverse Projekte und Guidelines mehr oder weniger willkürlich ausgearbeitet, welche später gefiltert und teilweise übernommen wurden.
Jedoch waren die NDAs nicht das einzige rechtliche Problem, welches einen Start verhinderte: Der Kauf der gesamten Software und der Maps hat sich verzögert, weswegen der Start der eigentlichen Entwicklung sich ebenfalls weiterhin verzögerte.
Die erste Dev Besprechung
Am 21.04.2021 fand somit die erste Dev Besprechung statt - alle NDAs wurden unterzeichnet und der Kauf der Projekte abgeschlossen.
In der ersten Besprechung wurde jedem Dev der Plan erläutert, welcher grob sich darum dreht, dass alle Projekte mittels CI/CD (Continuous Integration & Continuous Delivery) garantiert gebaut werden können und nicht jeder Entwickler lokal alle Abhängigkeiten in der richtigen Reihenfolge bauen muss, bevor er überhaupt dran denken kann ein Plugin zu entwickeln
Bevor die eigentliche Entwicklung beginnt
Wir mussten also 1. die relevanten Projekte finden, 2. sie in die richtigen Gruppen hinzufügen, 3. die Reihenfolge herausfinden, 4. Probleme beim Compilen beseitigen, 5. alle kaputten Versionen beseitigen und 6. CI/CD hinzufügen.
Jetzt werden einige Entwickler sagen: "Das macht man doch an einem Nachmittag?!?!"
Wir haben auch nur mit einzelnen Tagen gerechnet... bis wir die schiere Menge an Projekten und Abhängigkeiten überblicken konnten.
Dazu kurz ein paar Fakten:
- Lotus ist nach dem Vorbild von RewisServer im Jahr 2017 in 5 elementare Gruppen unterteilt: Web, Minecraft, Proxy, Network, AntiCheat und DevOps (kam neu hinzu)
- Manche Gruppen können auf die Projekte von anderen Gruppen zugreifen (z.B. AntiCheat auf Minecraft; Proxy auf Minecraft; DevOps auf alles), jedoch nicht umgekehrt ("Least privilege")
- Das Lotus GitLab zählt am 10.06.2021 insgesamt 643 einzelne Repositories - also grundlegend "Projekte", darunter alle Libraries, Plugins, Server, Proxies und Skripte, die je unter RewisServer oder Lotus entwickelt wurden - ausgenommen Babylon, welches auf GitHub öffentlich entwickelt wird. Natürlich ist nicht jedes der ~650 Projekte aktiv (viele sind mittlerweile Archiviert)
Während also diese Aufgaben nicht größtenteils beendet sind, kann kaum ein Entwickler produktiv arbeiten, was die gesamte Entwicklung extrem verzögert hat.
Zudem kam das Problem hinzu, dass man nicht komplett parallel, also 15 Entwickler bei ~650 Projekten, entwickeln konnte, sondern man sich an die uns bis dato unbekannte Reihenfolge halten musste, da sonst Abhängigkeiten zwischen den Projekten nicht funktionieren beim Kompilieren der Projekte - mal davon abgesehen, dass wir teilweise einzelne Projekte erstmal suchen mussten, da manche Repositories aus mehreren Modulen bestehen.
Jetzt sah es leider in der Praxis so aus, dass vornehmlich die erfahreneren Sr. Devs sich um diese Dinge gekümmert haben unter extremer Kommunikation untereinander, da niemals zwei Entwickler gleichzeitig ein Projekt bearbeiten sollten und man oft auf jemand anderen warten musste.
Circa einem Monat nach Start des Projektes, waren wir erst in der Lage einen PowerSpigot Server starten zu können mit den grundlegenden Plugins.
Wieso die Projekte nicht compiled werden können
Die Entwickler unter euch werden sich sicherlich bereits fragen, wieso wir denn die Plugins nicht einfach compilen konnten - und das ist eine sehr gute Frage!
Die Plugins basieren aufeinander, haben also Abhängigkeiten/Dependencies untereinander. Diese Dependencies verweisten oft auf Versionen, die es nicht mehr gibt - z.B. 0.1.0 statt 2.5.0. Das konnte bisher nur funktionieren, weil die vorherigen Entwickler diese alten Versionen bereits kompiliert hatten und diese somit auf dem Computer im lokalen Cache bereits vorhanden waren.
Jedoch ist dies nicht das einzige Problem: Es gab Cycle Dependencies - eine menge Cycle Dependencies...
Cycle Dependencies treten auf, wenn ein Projekt A auf B basiert und dieses wiederum auf A - also ein klassisches Henne-Ei-Problem.
Diese traten jedoch ebenfalls nicht bei den bisherigen Entwicklern auf, weil diese an irgendeiner Stelle bereits A oder B gebaut hatten in einer Version, die keine Cycle Dependency Fehler auslöst, was zwar funktioniert, aber im Falle einer komplett neuen Umgebung, wie wir sie nunmal haben, zu absolut katastrophalen Problemen führt.
Kotlin
Unter der vorherigen Leitung von RewisServer wurden einige elementare Projekte auf Kotlin umgeschrieben sowie neue Projekte gänzlich darin entwickelt. Jedoch haben wir uns dafür entschieden, soweit wie möglich, die wenigen Projekte auf Java umzuschreiben. Komplexere Projekte, welche jedoch weniger kritisch für Infrastruktur sind, werden vorerst auf Kotlin belassen und später (wenn das Netzwerk online ist) umgeschrieben/ersetzt.
War da nicht 'was mit Markennamen und Präfixen?
Während insbesondere Sr. Devs sich darum gekümmert haben, dass die direkt technischen Probleme gelöst werden, haben die restlichen Devs sich insbesondere den Markennamen, Backdoors und ingame Präfixen gewidmet, da diese aufgrund von rechtlichen Problemen zukünftig weder im Code noch ingame auftauchen dürfen.
Doch was sind "Backdoors" in diesem Kontext?
Backdoors sind entweder absichtlich oder aus Versehen nicht entfernte Code-Stellen, die gewissen Personen mehr Rechte verleihen. Ein Beispiel für "Backdoors" sind diverse Ausnahmen die explizit in AntiCheat-Systeme für rewinside eingebaut wurden, sodass er seine typischen Videos aufnehmen konnte (aus Zeiten vor Hackwars). Diese Backdoor ist vergleichsweise harmlos, sollte jedoch dringend entfernt werden.
Internationalisierung
In manchen Ankündigungen war auch von der Internationalisierung die Rede.
Diese ist ursprünglich eine Bestrebung der Leitung das Netzwerk beim Release direkt in mehreren Sprachen anbieten zu können.
Um dies zu erreichen wurde beispielsweise das Projekt Babylon von uns auf GitHub entwickelt und ein Konzept erarbeitet wie man dies für alle möglichen Plugins im Code umsetzt.
Aber das ist doch nicht wichtig?
Definitiv, die Internationalisierung ist nicht das Wichtigste, aber darum geht es auch gar nicht.
Wir haben bei Lotus momentan exakt 15 Entwickler, darunter auch Admins.
Diese setzen sich jedoch aus unterschiedlichen Gruppen zusammen: Web-Devs können nicht einfach bei Java Plugins mithelfen, können/müssen also komplett isoliert von Minecraft bezogenen Aufgaben arbeiten.
Dann haben wir, wie man bei den Markennamen und Präfixen gemerkt hat, auch unterschiedliche Skills bei den Entwicklern, weswegen wir nicht jedem Entwickler unsere schwersten Aufgaben zuweisen können, sondern unterteilen müssen zwischen "schweren" und "leichteren" Aufgaben, da es nichts bringt, wenn ein Entwickler für eine schwere Aufgabe eine Woche benötigt, während ein Sr. Dev dies in wenigen Stunden geschafft hätte.
Somit wurden Aufgaben so verteilt, dass diese insgesamt sehr effizient und flüssig abgearbeitet werden können.
Der Juni - Fortschritt zeichnet sich ab
Anfang Juni haben wir einen Stand, welcher es uns erstmals erlaubt eine einzelne Lobby und Minigames wie Bedwars und TryJump/GetDown zu starten, ohne die gesamte Infrastruktur lokal laufen zu haben.
In den Ankündigungen war von "lokalen Testen" die Rede, doch was heißt das genau?
Der bisherige Server wurde gegen Ende so umgeschrieben, dass es im Vergleich zu 2017 nicht mehr möglich war als Entwickler ein Minigame bei sich lokal zu entwickeln ohne die gesamte Infrastruktur laufen zu haben - es konnte also nur auf dem Testnetzwerk entwickelt werden.
Dies hatte bei Lotus zur Folge, dass wir, um die Trennung der Gruppen wiederherzustellen, die Stellen im Code, welche externe Systeme (BungeeCord, Cloud) benötigen, umschreiben mussten, sodass diese im sogenannten "offline" Modus laufen ohne Fehler zu erzeugen.
Das RIESIGE BungeeCord Update
BungeeCord als Proxy ist einer der wichtigsten und kritischsten Teile der Infrastruktur. Wenn wir von "Hackern", und damit meinen wir keine Cheater, angegriffen werden, ist der BungeeCord die prinzipiell erste Linie, die diese Angriffe abfangen muss.
Über die Zeit, angefangen in 2014 mit Howaner, wurde der BungeeCord immer mehr optimiert und gegen Angriffe abgesichert.
Dies hat sich insbesondere darin wiedergespigelt, dass unser modifizierte BungeeCord bis zu 2.000 Spieler pro Server aushalten konnte und damit eher eine 1Gbit Anbindung als den Prozessor überfordert hat - bei normalen BungeeCords liegt das Limit bei ca. 400 Spielern pro Instanz.
Das hört sich doch relativ gut an, wo ist das Problem?
Für die Modifikationen am BungeeCord wurde eine Technik namens "Forking" verwendet, welche uns erlaubt vom Origin (Ursprung), also dem originalen Quellcode, Änderungen jederzeit bei uns zu übernehmen - beispielsweise, wenn Lücken oder Bugs behoben wurden.
Als Howaner noch im Team war, wurde dies regelmäßig gemacht, jedoch mit der Zeit immer weniger, bis schlussendlich der BungeeCord auf der offiziellen Version von September 2017 war und nur noch intern Fehler behoben wurden.
Dies hatte zur Folge, dass einzelne Hacker durch manipulierte Pakete einen Denial of Service (DoS), also die kleine Variante eines DDoS, ausführen und damit die BungeeCords in die Knie zwingen konnten ohne viel Aufwand oder Kosten - das war einer der Gründe für Lags vor der Schließung. Zwar konnte man versuchen den Fehler selber zu finden, jedoch sollte man nicht vergessen, dass der BungeeCord die Meisten bekannten Fehler seit 2017 weiterhin im Code hatte.
Ergebnis war nun, dass wir ein Update des BungeeCords gemacht haben, welches 300+ Commits (Änderungen) beinhaltete. Bei einem unveränderten Fork wäre dies kein Problem, jedoch traten an allen Ecken und Kanten Konflikte auf, weil Code verändert wurde, der ebenfalls von md_5 (BungeeCord Hauptentwickler) verändert wurde in den letzten Jahren.
Diese mussten nun über eine Woche behoben und getestet werden.
Wie ist der jetzige Stand?
Heute sind wir an einem Punkt, dass wir die ersten Tests vorbereiten und alle Plugins grob funktional sind. Bedeutet wir starten interne Testphasen, welche uns aufzeigen sollen, ob das Netzwerk bereit für einen produktiven Einsatz ist, oder wir noch Bugs beheben müssen, die einem geordneten Release im Wege stehen.
Wir hoffen, euch hat dieser weitere Einblick gefallen. Abschließend bleibt noch folgendes zu sagen..
await nextDevBlog();