GitLab to platforma DevOps/DevSecOps do pracy z kodem (oparta na Git), która w jednym miejscu łączy repozytoria, zarządzanie projektami, CI/CD, narzędzia bezpieczeństwa i całą otoczkę wokół tworzenia oprogramowania. Można z niej korzystać jako z usługi w chmurze (GitLab.com) lub zainstalować ją na własnym serwerze, w VPS, chmurze publicznej czy u specjalizowanych dostawców hostingu GitLab.
- 1. Czym jest GitLab – prosty opis
- 2. GitLab a Git – na czym to się opiera?
- 3. Co dokładnie oferuje GitLab – główne funkcje
- 4. Jak działa GitLab – przegląd architektury i przepływu pracy
- 5. Gdzie hostować GitLab – możliwości i porównanie
- 6. GitLab na własnym serwerze – przykładowa instrukcja instalacji (Ubuntu)
- 7. Podstawowa konfiguracja projektu i CI/CD po instalacji
- 8. Kiedy GitLab ma największy sens?
To kompletny ekosystem: od planowania i kodowania, przez testy i automatyzację, aż po wdrożenia i bezpieczeństwo – wszystko w jednym narzędziu.
1. Czym jest GitLab – prosty opis
W najbardziej praktycznym ujęciu GitLab to:
- hosting repozytoriów Git – serwer, na którym przechowujesz kod z pełną historią zmian;
- platforma do pracy zespołowej – wbudowane issues, tablice zadań, code review, wiki i komentarze;
- platforma DevOps/DevSecOps – obsługa pełnego cyklu życia oprogramowania: od pomysłu, przez kod, testy i CI/CD, aż po wdrożenia i monitorowanie.
W skrócie to zintegrowana platforma do zarządzania kodem i procesami w projekcie, pozwalająca mieć kontrolę nad całym cyklem wytwarzania oprogramowania w jednym miejscu.
GitLab rozwija firma GitLab Inc., oferując wersję SaaS (GitLab.com) oraz wersje do samodzielnej instalacji (Community Edition – CE i płatne edycje Enterprise).
2. GitLab a Git – na czym to się opiera?
Różnice i zależności wyjaśnia krótkie zestawienie:
- Git – system kontroli wersji działający głównie w wierszu poleceń, służący do śledzenia zmian w kodzie;
- GitLab – aplikacja webowa, która udostępnia serwer Git, zapewnia interfejs WWW do przeglądania i zarządzania repozytoriami oraz dodaje warstwę DevOps (CI/CD, issues, merge requesty itd.).
Jak sama nazwa wskazuje, GitLab jest zbudowany na Git – użytkownicy pracują na kodzie w sposób uporządkowany, z pełną historią commitów, branchy i merge’y.
3. Co dokładnie oferuje GitLab – główne funkcje
3.1. Repozytoria Git i praca na kodzie
Podstawą GitLaba jest system zarządzania repozytorium Git.
W praktyce oznacza to m.in.:
- przechowywanie kodu w repozytoriach (publicznych lub prywatnych),
- przeglądanie commitów i porównywanie zmian (diffy),
- tworzenie branchy i ich łączenie (merge),
- code review przez Merge Requesty – dyskusje, komentarze do linii kodu, akceptacja zmian.
Wiele zadań, które zwykle wykonuje się w CLI, można zrobić wygodnie w przeglądarce.
3.2. Zarządzanie projektami i zespołem
GitLab oferuje szereg funkcji project management wbudowanych w tę samą architekturę DevOps:
- Issues – zgłoszenia zadań, błędów, funkcji;
- Tablice Kanban/Scrum – grupowanie issues w kolumnach, planowanie sprintów;
- Milestones – kamienie milowe i planowanie wydań;
- Wiki – dokumentacja projektu dostępna bezpośrednio przy kodzie.
Cały zespół pracuje w jednym narzędziu, bez przeskakiwania między wieloma systemami.
3.3. CI/CD – automatyzacja buildów, testów i wdrożeń
Jedną z najsilniejszych stron GitLaba jest wbudowany CI/CD (Continuous Integration/Continuous Delivery) – bez potrzeby instalowania dodatkowych wtyczek.
- w każdym repozytorium można dodać plik
.gitlab-ci.yml, - na jego podstawie GitLab uruchamia pipeline’y, czyli zautomatyzowane zadania: build, testy, analizy i wdrożenia,
- za wykonanie jobów odpowiada GitLab Runner – osobna aplikacja (na serwerze, VPS lub w kontenerze), która odbiera zadania z GitLaba i je wykonuje.
CI/CD umożliwia m.in.:
- automatyczne uruchamianie testów po każdym commicie,
- budowanie paczek i obrazów Docker,
- wdrażanie aplikacji na staging/produkcję,
- integrację z chmurami (AWS, GCP itp.).
3.4. Bezpieczeństwo i DevSecOps
GitLab rozwinął się w stronę DevSecOps, czyli włączania bezpieczeństwa w proces tworzenia oprogramowania.
Platforma zawiera m.in.:
- skanowanie podatności w kodzie,
- skanowanie zależności (SCA),
- narzędzia do compliance i audytu,
- raporty bezpieczeństwa.
Firmy mogą szybciej dostarczać oprogramowanie, jednocześnie wzmacniając bezpieczeństwo i zgodność z regulacjami.
4. Jak działa GitLab – przegląd architektury i przepływu pracy
4.1. Główne elementy
W typowym wdrożeniu GitLab składa się z kilku kluczowych komponentów:
- Instancja GitLab – aplikacja webowa, API i serwer Git;
- Baza danych i usługi pomocnicze – m.in. Redis, dostarczane w pakietach instalacyjnych;
- GitLab Runnerzy – agenci wykonujący zadania CI/CD.
GitLab może działać w różnych modelach:
- jako jedna maszyna (on‑premise, VPS),
- jako klastry (dla dużych organizacji),
- jako usługa w chmurze (GitLab.com).
4.2. Typowy workflow w GitLab
- Programista zakłada projekt w GitLab – repozytorium, ustawienia, uprawnienia.
- Klonuje repozytorium na swój komputer (
git clone) lub wysyła istniejący projekt do GitLab (git remote add origin+git push). - Pracuje lokalnie na branchach, robi commity, a następnie pushuje zmiany do GitLab.
- Tworzy Merge Request – prośbę o włączenie zmian do np.
main. - Inni członkowie zespołu robią code review, komentują i akceptują MR.
- Każdy push do brancha może odpalać pipeline CI/CD obejmujący:
- budowanie,
- testy,
- skan bezpieczeństwa,
- deployment.
- Po przejściu pipeline’ów MR jest scalany, a aplikacja może zostać automatycznie wdrożona.
GitLab zapewnia jeden, spójny punkt współpracy – od kodu po wdrożenie.
5. Gdzie hostować GitLab – możliwości i porównanie
GitLaba można hostować na kilka sposobów, a wybór zależy od potrzeb zespołu i wymogów formalnych:
| Opcja hostingu | Dla kogo | Plusy | Minusy |
|---|---|---|---|
| GitLab.com (SaaS) | Freelancerzy, małe zespoły, firmy bez adminów | Brak utrzymania serwera, szybki start, skalowalność | Dane poza pełną kontrolą organizacji, ograniczona personalizacja |
| Własny serwer / VPS | Średnie i duże firmy, projekty wymagające prywatności | Pełna kontrola, integracja z AD/LDAP, prywatność | Wymaga admina, dbałości o backupy, aktualizacje |
| Managed GitLab (dostawcy zewnętrzni) | Firmy chcące prywatności bez administrowania | Administracja po stronie dostawcy, wsparcie, lokalizacja danych (np. Europa) | Koszt abonamentu, mniejsza swoboda niż 100% własny serwer |
5.1. GitLab.com – najszybszy start
GitLab oferuje swoją oficjalną chmurę – GitLab.com. Proces uruchomienia wygląda następująco:
- rejestrujesz konto,
- zakładasz projekt,
- od razu masz repozytorium, CI/CD (ze współdzielonymi Runnerami GitLab.com) i resztę funkcji.
To bardzo dobre rozwiązanie:
- na początek,
- dla małych zespołów,
- dla projektów open source,
- tam, gdzie nie ma wymogu trzymania danych na własnej infrastrukturze.
5.2. Własny serwer GitLab (on‑premise / VPS)
GitLab można zainstalować na własnym serwerze (fizycznym, VPS, maszynie w chmurze).
Taki wariant jest często wybierany, ponieważ daje:
- pełną kontrolę nad danymi i konfiguracją,
- możliwość podpięcia LDAP/Active Directory (logowanie domenowe),
- łatwiejsze spełnienie wymogów prawnych i bezpieczeństwa (RODO, polityki korporacyjne).
To elastyczne, prywatne i przewidywalne środowisko pracy dla zespołów developerskich.
5.3. Zarządzany GitLab w chmurze (managed)
Istnieją dostawcy oferujący zarządzane instancje GitLab, hostowane np. w Europie.
Taki wariant zapewnia:
- pełne środowisko GitLab z administracją po stronie dostawcy,
- lokalizację danych (np. serwery w UE),
- wsparcie w konfiguracji i utrzymaniu.
To rozsądny kompromis między prywatnością własnego GitLaba a wygodą GitLab.com.
6. GitLab na własnym serwerze – przykładowa instrukcja instalacji (Ubuntu)
Poniżej znajdziesz uproszczony, ale praktyczny przegląd instalacji GitLab Community Edition (CE) na serwerze z Ubuntu – krok po kroku.
6.1. Wymagania wstępne
Przed startem upewnij się, że masz:
- serwer (fizyczny lub VPS) z Ubuntu (np. 20.04/22.04),
- uprawnienia
rootlubsudo, - domenę skierowaną DNS na IP serwera (np.
gitlab.twojadomena.pl), - swobodny port 80 i 443.
6.2. Instalacja pakietu GitLab CE
Na serwerze wykonaj kolejno (jako root lub z sudo):
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl postfix
Następnie dodaj repozytorium GitLab CE:
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
Zainstaluj GitLab CE, podając zewnętrzny adres instancji (HTTPS zalecany):
sudo EXTERNAL_URL="https://gitlab.twojadomena.pl" apt-get install gitlab-ce
Parametr EXTERNAL_URL definiuje publiczny adres instancji – GitLab automatycznie dopasuje konfigurację Nginx i aplikacji do tego URL.
6.3. HTTPS i certyfikaty SSL
Dla bezpieczeństwa instancja powinna działać po HTTPS. Dostępne są różne opcje:
- certyfikat z Let’s Encrypt (obsługiwany wbudowanie w GitLab),
- certyfikat komercyjny,
- certyfikat własny (np. wewnętrzna CA).
W typowym scenariuszu przejdź przez następujące kroki:
- Utwórz katalog na certyfikaty:
sudo mkdir -p /etc/gitlab/ssl
- Skopiuj pliki certyfikatu i klucza (np.
gitlab.twojadomena.pl.crtigitlab.twojadomena.pl.key). - Ustaw odpowiednie uprawnienia.
- Zaktualizuj konfigurację w
/etc/gitlab/gitlab.rb(ścieżki do certyfikatów, wymuszony HTTPS). - Przeładuj konfigurację GitLaba:
sudo gitlab-ctl reconfigure
6.4. Integracja z LDAP / Active Directory (opcjonalnie)
Jeżeli w firmie działa Active Directory/LDAP, użytkownicy mogą logować się danymi domenowymi.
W pliku /etc/gitlab/gitlab.rb skonfiguruj:
gitlab_rails['ldap_enabled'] = true,- parametry serwerów w
gitlab_rails['ldap_servers'](adres kontrolera domeny, DN, filtry itp.).
Po zapisaniu zmian zastosuj konfigurację:
sudo gitlab-ctl reconfigure
7. Podstawowa konfiguracja projektu i CI/CD po instalacji
Po zainstalowaniu GitLaba wykonaj wstępną konfigurację:
- Otwórz w przeglądarce
https://gitlab.twojadomena.pl. - Zaloguj się jako admin (przy pierwszym logowaniu ustaw hasło zgodnie z instrukcją na ekranie).
- Utwórz grupę (np.
moja-firma) i w niej projekt.
7.1. Dodanie istniejącego repozytorium
Jeśli masz lokalny projekt, który chcesz przenieść do GitLaba, postępuj tak:
- utwórz pusty projekt w GitLab (bez inicjalizacji README),
- w repozytorium lokalnym ustaw remote i wypchnij gałąź główną:
git remote add origin https://gitlab.twojadomena.pl/moja-firma/moj-projekt.git
git push -u origin main
Po tych krokach kod pojawi się w GitLab.
7.2. Pierwszy pipeline CI/CD
Aby skorzystać z CI/CD, w repozytorium dodaj plik .gitlab-ci.yml. Poniżej minimalny przykład dla projektu w Node.js:
stages:
- test
test_job:
stage: test
image: node:18
script:
- npm install
- npm test
Po każdym pushu GitLab:
- odczyta plik
.gitlab-ci.yml, - uruchomi pipeline i job
test_jobna skonfigurowanym GitLab Runnerze.
Aby Runner wykonywał zadania, pamiętaj o podstawowej konfiguracji:
- zainstaluj
gitlab-runnerna serwerze/VM/kontenerze, - zarejestruj go w swojej instancji GitLab (token znajdziesz w ustawieniach CI/CD projektu lub instancji),
- po rejestracji Runner będzie pobierał i wykonywał zadania.
8. Kiedy GitLab ma największy sens?
GitLab sprawdza się szczególnie, gdy:
- potrzebujesz nie tylko repozytorium, ale pełnej platformy DevOps/DevSecOps,
- zależy ci na jednym miejscu do planowania, pisania kodu, testów, wdrożeń i bezpieczeństwa,
- chcesz zautomatyzować jak najwięcej (CI/CD),
- musisz mieć kontrolę nad lokalizacją danych (własny serwer lub hosting w UE).
Dla polskich użytkowników istotne jest też, że:
- narzędzie jest szeroko opisane po polsku,
- istnieją lokalne poradniki i wdrożenia (np. integracja z UniCloud, instalacje w firmach),
- nie brakuje usługodawców oferujących managed GitLab z serwerami w Europie.
