Als unser Mitbegründer und Engineering Fellow Dmitriy Zaporozhets beschloss, GitLab zu entwickeln, entschied er sich für Ruby on Rails, obwohl er zu diesem Zeitpunkt hauptsächlich in PHP arbeitete. GitHub, eine Inspirationsquelle für GitLab, basierte ebenfalls auf Rails, was angesichts seines Interesses an diesem Framework eine logische Wahl war. Der CEO von GitLab, Sid Sijbrandij, ist der Meinung, dass sein Mitbegründer eine gute Wahl getroffen hat:
„Es hat sich wirklich bewährt, denn das Ruby on Rails-Ökosystem ermöglicht es, eine Vielzahl von Funktionen in hoher Qualität zu gestalten“, erklärt er. „Wenn man sich GitLab ansieht, hat es eine enorme Menge an Funktionalität. Die Softwareentwicklung ist sehr komplex, und um dabei zu helfen, brauchen wir viele Funktionen, und Ruby on Rails ist eine Möglichkeit, dies zu tun. Da es all diese Best Practices gibt, ist es auch eine Möglichkeit, den Code konsistent zu halten, wenn man etwas wie GitLab ausliefert. Man wird gewissermaßen dazu angeleitet, das Richtige zu tun.“
Abhängig von nützlichen Gems
Ruby-Gems spielen eine wesentliche Rolle bei der Erstellung von GitLab, da laut Sid mehr als tausend nicht-einzigartige Gems geladen werden. Er nennt das Ruby on Rails-Framework „sehr eigenwillig“ und ist der Meinung, dass es eine starke Umgebung ist, in der man eine komplexe Anwendung wie GitLab erstellen kann.
„Es gibt ein großartiges Ökosystem mit Gems, die Annahmen darüber machen können, wie man Dinge tut, und in dieser Hinsicht ist das Ruby on Rails-Ökosystem meiner Meinung nach immer noch unübertroffen“, sagt er. „Wenn man sich unser Gemfile ansieht, kann man erahnen, wie groß der Turm der Abhängigkeiten ist, auf dem wir aufbauen können. Ruby on Rails hat erstaunliche Schultern, auf denen wir stehen können, und es wäre viel langsamer gewesen, GitLab in einem anderen Framework zu entwickeln.“
Herausforderungen überwinden
Das alles soll nicht heißen, dass es keine Herausforderungen bei der Entwicklung von GitLab mit Ruby on Rails gegeben hat. Die Leistung war ein Problem, das unsere Entwickler auf verschiedene Weise verbessert haben, unter anderem durch das Umschreiben von Code in Go und die Verwendung des Vue-Frameworks. Letzteres wird verwendet, um häufig aufgerufene Seiten wie Issues und Merge-Requests umzuschreiben, damit sie schneller geladen werden, was die Benutzererfahrung verbessert.
Go wird verwendet, um andere Probleme zu beheben, die die Ladezeiten beeinträchtigen, und um die Speichernutzung zu reduzieren.
„Ruby wurde für den Entwickler optimiert, nicht für den Einsatz in der Produktion“, sagt Sid. „Für die Dinge, die sehr oft aufgerufen werden und sehr performant sein müssen oder die zum Beispiel sehr lange auf ein System-IO warten müssen, schreiben wir diese in Go um … Wir versuchen immer noch, GitLab dazu zu bringen, weniger Speicher zu verwenden. Wir müssen also Multithreading aktivieren. Als wir GitLab entwickelt haben, war das im Ruby on Rails-Ökosystem nicht üblich. Jetzt ist es üblicher, aber weil wir jetzt so viel Code und so viele Abhängigkeiten haben, wird es ein längerer Weg für uns sein, um dorthin zu gelangen. Das sollte helfen; es wird zwar nicht rasend schnell sein, aber zumindest wird es weniger Speicher verbrauchen.“
Die Aufnahme von Go in den Werkzeugkasten von GitLab führte zur Schaffung eines separaten Dienstes namens Gitaly, der alle Git-Anfragen abwickelt.
Aufbau auf der Mission von GitLab
Der organisierte, strukturierte Stil des Ruby on Rails-Frameworks passt zu unserer Kernmission. Weil Rails so schlank ist, kann jeder bei GitLab einsteigen und mitmachen, was es für Sid von Anfang an besonders attraktiv machte.
„Unsere Mission ist, dass jeder etwas beitragen kann“, erklärt er. „Da Ruby on Rails sehr eigenwillig ist, wenn es darum geht, welche Teile wo hingehören, ist es für neue Entwickler viel einfacher, in die Codebasis einzusteigen, weil man weiß, wo die Leute etwas hingelegt haben. In jeder Küche, die man betritt, weiß man zum Beispiel nie, wo die Messer und Teller liegen. Aber mit Ruby on Rails betritt man die Küche und sie ist immer am selben Ort, und das wollen wir beibehalten.
In jeder Küche, die man betritt, weiß man nie, wo die Messer und Teller sind. Aber bei Ruby on Rails betritt man die Küche und sie ist immer am selben Ort, und das wollen wir beibehalten.
„Ich war wirklich ermutigt, als ich das Projekt öffnete und es zum ersten Mal sah, ein Jahr nachdem Dmitriy damit angefangen hatte. Ich habe es geöffnet und es ist ein idiomatisches Rails. Er hat alle Prinzipien befolgt. Er hat nicht versucht, mit irgendeiner Modeerscheinung zu experimentieren, an der er interessiert war. Er hat es zu einer Produktionsanwendung gemacht. Dmitriy hat alle Beiträge sorgfältig geprüft, um sicherzustellen, dass sie sich an diese Konventionen halten, und das ist immer noch der Fall. Ich denke, wir haben eine sehr schöne Codebasis, die es anderen Leuten erlaubt, darauf aufzubauen. Einer unserer Unterwerte ist langweilige Lösungen: mach nichts Ausgefallenes. Das ist so, damit andere darauf aufbauen können. Ich denke, wir haben das wirklich gut gemacht … und wir sind wirklich dankbar, dass Ruby ein so stabiles Ökosystem ist, auf dem wir aufbauen können.“
Coverbild von Elvir K auf Unsplash
Schreibe einen Kommentar