När vår medgrundare och ingenjör Dmitriy Zaporozhets bestämde sig för att bygga GitLab valde han att göra det med Ruby on Rails, trots att han då främst arbetade i PHP. GitHub, en inspirationskälla för GitLab, var också baserad på Rails, vilket gjorde det till ett logiskt val med tanke på hans intresse för ramverket. GitLabs vd Sid Sijbrandij anser att hans medgrundare gjorde ett bra val:
”Det har fungerat riktigt bra eftersom ekosystemet Ruby on Rails gör det möjligt att utforma många funktioner med hög kvalitet”, förklarade han. ”Om du tittar på GitLab har det en enorm mängd funktionalitet. Programvaruutveckling är mycket komplex och för att hjälpa till med det behöver vi mycket funktionalitet och Ruby on Rails är ett sätt att göra det. Eftersom det finns alla dessa bästa metoder som finns på din lyckliga väg är det också ett sätt att hålla koden konsekvent när du skickar något som GitLab. Du blir på sätt och vis guidad att göra rätt saker.”
Avhängigt av användbara gems
Ruby gems spelar en viktig roll i byggandet av GitLab, där det laddas in mer än tusen icke-unikartade gems, enligt Sid. Han kallar Ruby on Rails-ramverket för ”väldigt åsiktsstyrt” och anser att det är en stark miljö för att bygga en komplex app som GitLab.
”Det finns ett stort ekosystem runtomkring med gems som kan göra antaganden om hur du gör saker och ting och i det avseendet tycker jag att Ruby on Rails-ekosystemet fortfarande är oöverträffat”, säger han. ”Om du tittar på vår Gemfile får du en indikation på hur stort tornet är av beroenden som vi kan bygga på. Ruby on Rails har fantastiska axlar att stå på och det skulle ha varit mycket långsammare att utveckla GitLab i något annat ramverk.”
Övervinna utmaningar
Allt detta betyder inte att det inte har funnits utmaningar när det gäller att bygga GitLab med Ruby on Rails. Prestanda har varit ett problem som våra utvecklare har gjort stora ansträngningar för att förbättra på flera sätt, bland annat genom att skriva om kod i Go och använda Vue-ramverket. Det sistnämnda används för att skriva om ofta använda sidor, t.ex. frågor och sammanslagningsförfrågningar, så att de laddas snabbare, vilket förbättrar användarupplevelsen.
Go används för att ta itu med andra problem som påverkar laddningstiderna och för att minska minnesanvändningen.
”Ruby optimerades för utvecklaren, inte för att köras i produktion”, säger Sid. ”När det gäller de saker som drabbas mycket och som måste vara mycket prestanda eller som till exempel måste vänta mycket länge på en system-IO skriver vi om dem i Go … Vi försöker fortfarande få GitLab att använda mindre minne. Därför måste vi aktivera multithreading. När vi utvecklade GitLab var detta inte vanligt i Ruby on Rails-ekosystemet. Nu är det vanligare, men eftersom vi nu har så mycket kod och så många beroenden kommer det att bli en längre väg för oss att nå dit. Det borde hjälpa; det kommer inte att göra det rasande snabbt, men det kommer åtminstone att använda mindre minne.”
Att lägga till Go i GitLabs verktygslåda ledde till skapandet av en separat tjänst kallad Gitaly, som hanterar alla Git-förfrågningar.
Bygga vidare på GitLabs uppdrag
Den organiserade, strukturerade stilen hos ramverket i Ruby on Rails ligger i linje med vårt kärnuppdrag. Eftersom Rails är strömlinjeformat kan vem som helst hoppa in i GitLab och delta, vilket gjorde det särskilt attraktivt för Sid från början.
”Vårt uppdrag är att alla ska kunna bidra”, förklarar han. ”Eftersom Ruby on Rails är väldigt åsiktsstyrt när det gäller vilka delar som ska vara var, är det mycket lättare för nya utvecklare att ta sig in i kodbasen, eftersom man vet var folk har lagt saker och ting. I varje kök du kommer in i vet du till exempel aldrig var knivarna och tallrikarna är placerade. Men med Ruby on Rails kommer man in i köket och det är alltid på samma ställe, och det vill vi hålla oss till.
I varje kök man kommer in i vet man aldrig var knivarna och tallrikarna är placerade. Men med Ruby on Rails går du in i köket och det är alltid på samma ställe, och det vill vi hålla oss till.
”Jag blev verkligen uppmuntrad när jag öppnade projektet och såg det för första gången ett år efter att Dmitriy startade det. Jag öppnade det och det är idiomatiskt Rails. Han följde alla principer. Han försökte inte experimentera med någon slags modefluga som han var intresserad av. Han gjorde det till en produktionsapplikation. Dmitriy granskade noggrant alla bidrag för att se till att de höll sig till dessa konventioner, och så är det fortfarande. Jag tycker att vi har en mycket trevlig kodbas som gör det möjligt för andra att bygga på den. En av våra undervärden är tråkiga lösningar: gör inget märkvärdigt. Detta är för att andra ska kunna bygga på det. Jag tycker att vi har gjort det riktigt bra … och vi är verkligen tacksamma för att Ruby har varit ett så stabilt ekosystem för oss att bygga på.”
Omslagsbild av Elvir K på Unsplash
Lämna ett svar