Kiedy nasz współzałożyciel i inżynier Dmitriy Zaporozhets zdecydował się zbudować GitLab, wybrał Ruby on Rails, mimo że w tamtym czasie pracował głównie w PHP. GitHub, źródło inspiracji dla GitLab, był również oparty na Railsach, co czyniło go logicznym wyborem, biorąc pod uwagę jego zainteresowanie tym frameworkiem. Sid Sijbrandij, dyrektor generalny GitLab, uważa, że jego współzałożyciel dokonał dobrego wyboru:
„Sprawdziło się to naprawdę dobrze, ponieważ ekosystem Ruby on Rails pozwala na kształtowanie wielu funkcjonalności przy zachowaniu wysokiej jakości”, wyjaśnił. „Jeśli spojrzysz na GitLab, ma on ogromną ilość funkcjonalności. Tworzenie oprogramowania jest bardzo złożone i aby w tym pomóc, potrzebujemy wielu funkcjonalności, a Ruby on Rails jest sposobem, aby to zrobić. Ponieważ wszystkie te najlepsze praktyki są na twojej szczęśliwej ścieżce, jest to również sposób na utrzymanie spójności kodu, kiedy dostarczasz coś takiego jak GitLab. Jesteś jakby prowadzony do robienia właściwych rzeczy.”
Zależność od użytecznych klejnotów
Klejnoty Ruby odgrywają integralną rolę w budowaniu GitLaba, z ładowaniem ponad tysiąca nie-unikalnych klejnotów, według Sida. Nazywając framework Ruby on Rails „bardzo opiniotwórczym”, Sid uważa, że jest to silne środowisko, w którym można zbudować tak złożoną aplikację jak GitLab.
„Wokół niego istnieje wspaniały ekosystem z klejnotami, które mogą robić założenia na temat tego, jak robisz rzeczy i pod tym względem myślę, że ekosystem Ruby on Rails jest wciąż bezkonkurencyjny” – mówi. „Jeśli spojrzysz na nasz Gemfile, możesz zobaczyć, jak duża jest wieża zależności, na których możemy budować. Ruby on Rails ma niesamowite ramiona, na których można się oprzeć, a rozwój GitLaba w jakimkolwiek innym frameworku byłby znacznie wolniejszy.”
Pokonywanie wyzwań
Wszystko to nie oznacza, że budowanie GitLab z Ruby on Rails nie wiązało się z żadnymi wyzwaniami. Wydajność była problemem, który nasi programiści starali się poprawić na wiele sposobów, w tym przepisując kod w Go i używając frameworka Vue. Ten ostatni jest używany do przepisywania często odwiedzanych stron, takich jak sprawy i prośby o scalenie, aby ładowały się szybciej, poprawiając doświadczenie użytkownika.
Go jest używane do rozwiązywania innych problemów wpływających na czas ładowania i zmniejszania zużycia pamięci.
„Ruby został zoptymalizowany dla deweloperów, a nie do pracy na produkcji”, mówi Sid. „W przypadku rzeczy, które są często uruchamiane i muszą być bardzo wydajne lub które, na przykład, muszą czekać bardzo długo na IO systemu, przepisujemy je w Go … Nadal staramy się, aby GitLab zużywał mniej pamięci. Tak więc, będziemy musieli włączyć wielowątkowość. Kiedy tworzyliśmy GitLaba, nie było to powszechne w ekosystemie Ruby on Rails. Teraz jest to bardziej powszechne, ale ponieważ mamy teraz tak dużo kodu i tak wiele zależności, będzie to dla nas dłuższa droga do osiągnięcia tego celu. To powinno pomóc; nie sprawi, że będzie to szalenie szybkie, ale przynajmniej będzie zużywać mniej pamięci.”
Dodanie Go do zestawu narzędzi GitLab doprowadziło do stworzenia oddzielnej usługi o nazwie Gitaly, która obsługuje wszystkie żądania Git.
Budowanie na misji GitLab
Zorganizowany, uporządkowany styl frameworka Ruby on Rails jest zgodny z naszą główną misją. Ponieważ Railsy są uproszczone, każdy może wskoczyć do GitLab i uczestniczyć w projekcie, co sprawiło, że od początku był on szczególnie atrakcyjny dla Sida.
„Naszą misją jest to, że każdy może wnieść swój wkład,” wyjaśnia. „Ponieważ Ruby on Rails jest naprawdę opiniotwórczy w kwestii tego, które elementy gdzie się znajdują, nowym programistom jest o wiele łatwiej dostać się do bazy kodu, ponieważ wiesz, gdzie ludzie umieścili poszczególne elementy. Na przykład, w każdej kuchni, do której wchodzisz, nigdy nie wiesz, gdzie znajdują się noże i talerze. Ale z Ruby on Rails, wchodzisz do kuchni i zawsze jest ona w tym samym miejscu i chcemy się tego trzymać.
W każdej kuchni do której wchodzisz, nigdy nie wiesz gdzie znajdują się noże i talerze. Ale z Ruby on Rails, wchodzisz do kuchni i zawsze jest ona w tym samym miejscu i tego chcemy się trzymać.
„Byłem naprawdę podbudowany, kiedy otworzyłem projekt i zobaczyłem go po raz pierwszy rok po tym, jak Dmitriy go rozpoczął. Otworzyłem go i okazało się, że to idiomatyczne Railsy. Podążał za wszystkimi zasadami. Nie próbował eksperymentować z jakąś modą, która go interesowała. Zrobił z tego aplikację produkcyjną. Dmitriy starannie weryfikował wszystkie wkłady, aby upewnić się, że trzymają się tych konwencji, i tak jest nadal. Myślę, że mamy bardzo fajną bazę kodową, która pozwala innym ludziom budować na jej podstawie. Jedną z naszych pod-wartości są nudne rozwiązania: nie rób nic wymyślnego. To po to, aby inni mogli na tym budować. Myślę, że zrobiliśmy to naprawdę dobrze … i jesteśmy wdzięczni, że Ruby jest tak stabilnym ekosystemem, na którym możemy budować.”
Cover image by Elvir K on Unsplash
Dodaj komentarz