Toen onze mede-oprichter en Engineering Fellow Dmitriy Zaporozhets besloot om GitLab te bouwen, koos hij ervoor om het met Ruby on Rails te doen, ondanks dat hij op dat moment voornamelijk in PHP werkte. GitHub, een inspiratiebron voor GitLab, was ook gebaseerd op Rails, waardoor het een logische keuze was gezien zijn interesse in het framework. GitLab CEO Sid Sijbrandij denkt dat zijn mede-oprichter een goede keuze heeft gemaakt:

“Het heeft heel goed uitgepakt omdat het Ruby on Rails ecosysteem je in staat stelt om veel functionaliteit vorm te geven tegen een hoge kwaliteit,” legt hij uit. “Als je kijkt naar GitLab, het heeft een enorme hoeveelheid functionaliteit. Softwareontwikkeling is erg complex en om daarbij te helpen, hebben we veel functionaliteit nodig en Ruby on Rails is een manier om dat te doen. Omdat er al deze best practices op je pad komen, is het ook een manier om de code consistent te houden als je iets als GitLab verscheept. Je wordt als het ware geleid om het juiste te doen.”

Afhankelijk van bruikbare gems

Ruby gems spelen een integrale rol in het bouwen van GitLab, met het laden van meer dan duizend niet-unieke gems, volgens Sid. Hij noemt het Ruby on Rails framework “erg eigenwijs,” en denkt dat het een sterke omgeving is om een complexe app als GitLab te bouwen.

“Er zit een geweldig ecosysteem omheen met gems die aannames kunnen doen over hoe je dingen doet en in dat opzicht denk ik dat het Ruby on Rails ecosysteem nog steeds zonder gelijke is,” zegt hij. “Als je naar onze Gemfile kijkt, geeft het je een indicatie van hoe groot de toren is van afhankelijkheden waar we op kunnen bouwen. Ruby on Rails heeft geweldige schouders om op te staan en het zou veel langzamer zijn geweest om GitLab in een ander framework te ontwikkelen.”

Uitdagingen overwinnen

Nieuwe blogberichten direct in je inbox
Teken in voor onze tweemaandelijkse nieuwsbrief

Bedankt, je
hebt je ingeschreven!
GitLab komt naar uw inbox

Dit alles wil niet zeggen dat er geen uitdagingen zijn geweest bij het bouwen van GitLab met Ruby on Rails. Prestaties zijn een probleem geweest dat onze ontwikkelaars op een aantal manieren hebben verbeterd, waaronder het herschrijven van code in Go en het gebruik van het Vue-framework. Het laatste wordt gebruikt om veelgebruikte pagina’s te herschrijven, zoals issues en samenvoegverzoeken, zodat ze sneller laden en de gebruikerservaring verbetert.

Go wordt gebruikt om andere problemen aan te pakken die laadtijden beïnvloeden en het geheugengebruik te verminderen.

“Ruby was geoptimaliseerd voor de ontwikkelaar, niet om het in productie te draaien,” zegt Sid. “Voor de dingen die veel geraakt worden en erg performant moeten zijn of die, bijvoorbeeld, erg lang moeten wachten op een systeem IO, herschrijven we die in Go … We proberen nog steeds om GitLab minder geheugen te laten gebruiken. Dus, moeten we multithreading inschakelen. Toen we GitLab ontwikkelden was dat niet gebruikelijk in het Ruby on Rails ecosysteem. Nu is het meer gebruikelijk, maar omdat we nu zoveel code en afhankelijkheden hebben, zal het een langere weg voor ons zijn om daar te komen. Dat zou moeten helpen; het zal het niet razendsnel maken, maar het zal in ieder geval minder geheugen gebruiken.”

Het toevoegen van Go aan GitLab’s gereedschapskist leidde tot de creatie van een aparte service genaamd Gitaly, die alle Git verzoeken afhandelt.

Bouwen op GitLab’s missie

De georganiseerde, gestructureerde stijl van Ruby on Rails’ framework valt in lijn met onze kernmissie. Omdat Rails gestroomlijnd is, kan iedereen in GitLab springen en meedoen, wat het voor Sid vanaf het begin bijzonder aantrekkelijk maakte.

“Onze missie is dat iedereen kan bijdragen,” legt hij uit. “Omdat Ruby on Rails echt een eigen mening heeft over welke stukken waar moeten komen, is het veel makkelijker voor nieuwe ontwikkelaars om in de codebase te komen, omdat je weet waar mensen dingen hebben neergezet. Bijvoorbeeld, in elke keuken waar je binnenkomt, weet je nooit waar de messen en borden liggen. Maar met Ruby on Rails kom je de keuken binnen en die staat altijd op dezelfde plaats, en daar willen we ons aan houden.

In elke keuken waar je binnenkomt, weet je nooit waar de messen en borden staan. Maar met Ruby on Rails kom je de keuken binnen en die staat altijd op dezelfde plaats, en daar willen we ons aan houden.

“Ik was echt bemoedigd toen ik het project opende en het voor het eerst zag, een jaar nadat Dmitriy ermee was begonnen. Ik opende het en het is idiomatisch Rails. Hij volgde alle principes. Hij probeerde niet te experimenteren met een of andere rage waar hij in geïnteresseerd was. Hij maakte er een productie applicatie van. Dmitriy heeft alle bijdragen zorgvuldig doorgelicht om er zeker van te zijn dat ze zich aan die conventies houden, en dat is nog steeds het geval. Ik denk dat we een hele mooie codebase hebben waar andere mensen op kunnen bouwen. Een van onze subwaarden is saaie oplossingen: doe niets bijzonders. Dit is zodat anderen er bovenop kunnen bouwen. Ik denk dat we dat heel goed hebben gedaan… en we zijn echt dankbaar dat Ruby zo’n stabiel, ecosysteem voor ons is geweest om op te bouwen.”

Bekledingsafbeelding door Elvir K op Unsplash