Da vores medstifter og Engineering Fellow Dmitriy Zaporozhets besluttede at bygge GitLab, valgte han at gøre det med Ruby on Rails, selv om han primært arbejdede i PHP på det tidspunkt. GitHub, som var en inspirationskilde for GitLab, var også baseret på Rails, hvilket gjorde det til et logisk valg i betragtning af hans interesse for dette framework. GitLabs administrerende direktør Sid Sijbrandij mener, at hans medstifter traf et godt valg:
“Det har fungeret rigtig godt, fordi Ruby on Rails-økosystemet giver dig mulighed for at forme en masse funktionalitet i høj kvalitet”, forklarede han. “Hvis du kigger på GitLab, så har det en enorm mængde funktionalitet. Softwareudvikling er meget kompleks, og for at hjælpe med det har vi brug for en masse funktionalitet, og Ruby on Rails er en måde at gøre det på. Fordi der er alle disse best practices, der er på din lykkelige vej, er det også en måde at holde koden konsistent på, når du sender noget som GitLab. Du bliver på en måde guidet til at gøre det rigtige.”
Afhænger af nyttige gems
Ruby-gems spiller en integreret rolle i opbygningen af GitLab, idet den ifølge Sid indlæser mere end tusind ikke-unikke gems. Han kalder Ruby on Rails-rammen for “meget holdningspræget” og mener, at det er et stærkt miljø, hvor man kan bygge en kompleks app som GitLab.
“Der er et fantastisk økosystem omkring det med gems, der kan lave antagelser om, hvordan du gør tingene, og i den henseende mener jeg, at Ruby on Rails-økosystemet stadig er uden sammenligning,” siger han. “Hvis du kigger på vores Gemfile, giver den dig en indikation af, hvor stort tårnet er af afhængigheder, som vi kan bygge på. Ruby on Rails har fantastiske skuldre at stå på, og det ville have været meget langsommere at udvikle GitLab i et andet framework.”
Overcoming challenges
Alt dette betyder ikke, at der ikke har været udfordringer ved at bygge GitLab med Ruby on Rails. Ydelsen har været et problem, som vores udviklere har gjort fremskridt for at forbedre på en række måder, herunder ved at omskrive kode i Go og bruge Vue-rammen. Sidstnævnte bruges til at omskrive sider med hyppig adgang, f.eks. issues og merge requests, så de indlæses hurtigere, hvilket forbedrer brugeroplevelsen.
Go bruges til at løse andre problemer, der påvirker indlæsningstiderne, og til at reducere hukommelsesforbruget.
“Ruby blev optimeret til udvikleren, ikke til at køre det i produktion,” siger Sid. “For de ting, der bliver ramt meget og skal være meget performante, eller som f.eks. skal vente meget længe på en system-IO, omskriver vi dem i Go … Vi forsøger stadig at få GitLab til at bruge mindre hukommelse. Så vi bliver nødt til at aktivere multithreading. Da vi udviklede GitLab, var det ikke almindeligt i Ruby on Rails-økosystemet. Nu er det mere almindeligt, men fordi vi nu har så meget kode og så mange afhængigheder, vil det være en længere vej for os at nå dertil. Det burde hjælpe; det vil ikke gøre det lynhurtigt, men det vil i det mindste bruge mindre hukommelse.”
Den tilføjelse af Go til GitLabs værktøjskasse førte til oprettelsen af en separat tjeneste kaldet Gitaly, som håndterer alle Git-forespørgsler.
Bygger på GitLabs mission
Den organiserede, strukturerede stil i Ruby on Rails’ framework falder i tråd med vores kerneopgave. Fordi Rails er strømlinet, kan alle hoppe ind i GitLab og deltage, hvilket gjorde det særligt attraktivt for Sid fra starten.
“Vores mission er, at alle kan bidrage,” forklarer han. “Fordi Ruby on Rails virkelig har en mening om, hvilke dele der hører til hvor, er det meget lettere for nye udviklere at komme ind i kodebasen, fordi man ved, hvor folk har lagt ting. For eksempel ved man aldrig i alle de køkkener, man kommer ind i, hvor knivene og tallerknerne er placeret. Men med Ruby on Rails kommer man ind i køkkenet, og det er altid det samme sted, og det vil vi gerne holde os til.
I hvert køkken, man kommer ind i, ved man aldrig, hvor knivene og tallerknerne er placeret. Men med Ruby on Rails kommer du ind i køkkenet, og det er altid det samme sted, og det vil vi gerne holde os til.
“Jeg blev virkelig opmuntret, da jeg åbnede projektet og så det for første gang et år efter, at Dmitriy startede det. Jeg åbnede det, og det er idiomatisk Rails. Han fulgte alle principperne. Han forsøgte ikke at eksperimentere med en eller anden modefænomen, som han var interesseret i. Han gjorde det til en produktionsapplikation. Dmitriy gennemgik omhyggeligt alle bidrag for at sikre, at de holdt sig til disse konventioner, og det er stadig tilfældet. Jeg synes, at vi har en meget fin kodebase, som gør det muligt for andre at bygge oven på den. En af vores underværdier er kedelige løsninger: lad være med at lave noget fancy. Det er for at andre kan bygge oven på det. Jeg synes, vi har gjort det rigtig godt … og vi er virkelig taknemmelige for, at Ruby har været et så stabilt økosystem, som vi har kunnet bygge på.”
Overstebillede af Elvir K på Unsplash
Skriv et svar