GitLab — podstawy, możliwości i CI/CD

Co to jest GitLab?

GitLab — to pełnoprawna platforma DevOps z otwartym kodem źródłowym na licencji MIT. W przeciwieństwie do GitHub, który łączy różne usługi poprzez integracje, GitLab zapewnia jednolite narzędzie dla całego cyklu życia rozwoju: od zarządzania kodem i code review po CI/CD, monitorowanie, bezpieczeństwo i wdrażanie. Platforma nie wymaga zewnętrznych usług dla większości zadań DevOps.

Historia GitLab rozpoczęła się w 2011 roku jako wewnętrzny projekt ukraińskich programistów. Pierwsza publiczna wersja ukazała się we wrześniu 2011 roku, a w 2015 roku GitLab stał się pierwszym projektem na GitLab.com, uruchamiając hosting w chmurze. W 2017 roku GitLab przeprowadził bolesny, ale pouczający proces migracji — przeniesienie całej infrastruktury z Azure do Google Cloud, który był transmitowany na żywo i udokumentowany w serii wpisów.

Architektura GitLab składa się z trzech głównych komponentów: GitLab Rails (aplikacja webowa w Ruby on Rails), GitLab Shell (obsługa operacji Git przez SSH) i Gitaly (serwer gRPC do dostępu do danych Git). CI/CD jest zapewniane przez GitLab Runner — oddzielną aplikację instalowaną na serwerach budowania, która wykonuje zadania w izolowanych środowiskach (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipeline'y i runnery

GitLab CI/CD — to wbudowany system ciągłej integracji i dostarczania, który jest kluczową zaletą platformy. W przeciwieństwie do GitHub Actions, GitLab CI/CD był wbudowany w architekturę od samego początku i nie wymaga osobnej konfiguracji: każdy projekt automatycznie otrzymuje CI/CD po dodaniu pliku .gitlab-ci.yml do katalogu głównego repozytorium.

Pipeline (pipeline) składa się z etapów (stages), które są wykonywane sekwencyjnie lub równolegle: build → test → deploy. Każdy etap zawiera jedno lub więcej zadań (jobs), które są wykonywane na runnerach. Jeśli jedno zadanie w etapie zakończy się błędem, cały etap jest oznaczany jako failed, a kolejne etapy nie są uruchamiane domyślnie. Poniżej znajduje się przykład pipeline'a dla projektu mobilnego:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner obsługuje kilka executor (wykonawców): Docker (zalecany), Kubernetes, SSH, VirtualBox i Parallels. Najpopularniejszym wariantem jest wykonawca Docker, który uruchamia każde zadanie w osobnym kontenerze. Runner można zarejestrować jako specyficzny dla jednego projektu lub jako wspólny (shared) dla całej grupy. GitLab.com zapewnia darmowe shared runnery z limitem 2000 minut miesięcznie.

Zaawansowane możliwości CI/CD

GitLab CI/CD obsługuje uruchamianie ręczne (when: manual), uruchamianie opóźnione (when: delayed), wykonywanie równoległe (parallel: 5), macierz (matrix), dynamiczne pipeline'y (child pipelines) i wielopoziomowe pipeline'y (parent-child). Pozwala to budować złożone scenariusze: na przykład dynamicznie generować pipeline dla każdego modułu w monorepozytorium lub uruchamiać równoległe kompilacje dla różnych architektur Androida (arm64, x86_64).

GitLab kontra GitHub: kluczowe różnice

GitLab i GitHub — to dwaj główni konkurenci na rynku platform Git, ale ich filozofia i architektura zasadniczo się różnią. GitHub stawia na otwartą społeczność, ekosystem integracji i funkcje społecznościowe (forki, gwiazdki). GitLab koncentruje się na kompleksowym cyklu DevOps i zapewnia wszystkie narzędzia od razu po wyjęciu z pudełka: od planowania po monitorowanie.

Podstawowa różnica architektoniczna: GitLab — to jedna monolityczna aplikacja, którą programista instaluje w całości. Wszystkie funkcje (CI/CD, Container Registry, Security Scanning, Pages) są wbudowane i działają od razu po instalacji. GitHub — to platforma z API, gdzie większość funkcji jest realizowana przez integrację z zewnętrznymi usługami: Travis CI, CircleCI, Jenkins, SonarQube. Poniższa tabela porównuje kluczowe cechy:

Wybór między GitLab a GitHub zależy od potrzeb zespołu. Jeśli priorytetem jest szybkie wdrożenie z zerową konfiguracją i otwarta społeczność — wybierz GitHub. Jeśli potrzebne jest pełne zarządzanie infrastrukturą, własny hosting i wbudowane bezpieczeństwo — GitLab jest lepszym wyborem. Według ankiety Stack Overflow (2024), GitHub używa 90% programistów, GitLab — 33% (często obie platformy jednocześnie).

Self-Managed GitLab: instalacja na własnym serwerze

Self-Managed GitLab (wcześniej On-Premises) pozwala zainstalować platformę na własnym serwerze i uzyskać pełną kontrolę nad danymi, infrastrukturą i dostępnością. Jest to szczególnie ważne dla organizacji z wymogami compliance: sektor finansowy, instytucje rządowe, organizacje medyczne, gdzie dane nie mogą być przechowywane na zewnętrznych serwerach.

Instalacja GitLab jest obsługiwana na Ubuntu, Debian, CentOS i przez Docker. Oficjalny pakiet Omnibus zawiera wszystkie komponenty: serwer webowy (NGINX), bazę danych (PostgreSQL), pamięć podręczną (Redis), procesor Git (Gitaly) i procesy tła. Minimalne wymagania: 4 GB RAM i 2 CPU dla zespołu do 100 osób. Dla dużych instalacji z wysokim obciążeniem zaleca się rozdzielenie komponentów na osobne serwery.

# Instalacja GitLab CE na Ubuntu przez Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Instalacja pakietu
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Sprawdzenie statusu
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab nie ma ograniczeń minut CI/CD — wszystkie runnery należą do organizacji, a ich moc jest ograniczona tylko własnym sprzętem. Dostępne są również Geo-replikacja dla regionów, dzienniki audytu, blokowanie IP i integracja z korporacyjnymi dostawcami LDAP/SAML. GitLab wydaje aktualizacje co miesiąc (22-go dnia) z nowymi funkcjami i poprawkami bezpieczeństwa.

Wbudowane narzędzia bezpieczeństwa GitLab

Bezpieczeństwo w GitLab jest wbudowane na poziomie platformy i obejmuje kilka skanerów działających na każdym etapie pipeline'a. SAST (Static Application Security Testing) analizuje kod źródłowy pod kątem podatności bez uruchamiania aplikacji, obsługując ponad 15 języków, w tym Java, Kotlin, Swift, Python i JavaScript. DAST (Dynamic Application Security Testing) testuje uruchomioną aplikację webową pod kątem podatności od wewnątrz.

Dodatkowe narzędzia: Container Scanning sprawdza obrazy Docker pod kątem podatności w warstwach bazowych; Dependency Scanning analizuje zależności projektu i ostrzega o znanych CVE; Secret Detection znajduje przypadkowo zakomitowane klucze API, hasła i tokeny; Fuzz Testing wykonuje automatyczne testowanie z nieprawidłowymi danymi w celu znalezienia nieoczywistych błędów. Wszystkie wyniki skanowania są wyświetlane w jednym Security Dashboard.

GitLab zapewnia również Compliance — narzędzia do spełniania wymogów regulacyjnych. Compliance Dashboard pokazuje status zgodności wszystkich projektów, Audit Events rejestruje każde działanie administratora i programisty, a Compliance Frameworks pozwalają wymuszać polityki konfiguracji dla określonych grup projektów. To sprawia, że GitLab jest popularnym wyborem w korporacyjnych środowiskach z rygorystycznymi wymogami bezpieczeństwa.

Container Registry i Dependency Proxy

GitLab Container Registry — to wbudowany rejestr Docker zintegrowany z CI/CD. Po zbudowaniu obrazu Docker w pipeline'ie można go natychmiast opublikować w Registry, używając zmiennych środowiskowych CI_REGISTRY i CI_REGISTRY_USER. Registry obsługuje cache'owanie pull-through, tagowanie, polityki czyszczenia i skanowanie pod kątem podatności bezpośrednio w rejestrze.

Dependency Proxy — mechanizm cache'owania kontenerów i obrazów z zewnętrznych rejestrów (Docker Hub, Quay, GCR). Gdy pipeline żąda obrazu ubuntu:latest, GitLab najpierw sprawdza swój cache — jeśli obraz został już pobrany, nie jest pobierany ponownie. Zmniejsza to obciążenie zewnętrznych rejestrów, przyspiesza pipeline'y i chroni przed limitami szybkości Docker Hub.

Dla programistów mobilnych GitLab zapewnia GitLab Pages do hostowania dokumentacji i raportów testowych. Po przebiegu testów artefakty (raporty HTML, zrzuty ekranu, logi) można opublikować jako Pages i uzyskać link do wysłania zespołowi QA. Jest to wygodniejsze niż przesyłanie raportów do magazynu w chmurze, ponieważ wszystko jest umieszczane w ramach tego samego projektu GitLab.

GitLab API i Webhooki

GitLab API (REST i GraphQL) zapewnia dostęp do wszystkich zasobów platformy: projekty, użytkownicy, pipeline'y, Merge Request, rejestr. API jest używane do automatyzacji: tworzenia projektu z szablonu, przypisywania rewizera, pobierania statusu pipeline'a. Webhooki pozwalają wysyłać powiadomienia HTTP do zewnętrznych systemów przy zdarzeniach: push, merge, utworzenie Issue. Webhooki integrują się z Mattermost, Slack, Telegram i wewnętrznymi systemami monitorowania.

GitLab Pages dla dokumentacji mobilnej

GitLab Pages automatycznie publikuje statyczne strony z repozytorium. Dla projektów mobilnych Pages jest wygodny do umieszczania dokumentacji API, raportów pokrycia testami i wyników analizy lint. Publikacja następuje automatycznie po udanym pipeline'ie — wystarczy wskazać w .gitlab-ci.yml krok deploy z publikacją w Pages. Wynik jest dostępny pod adresem https://namespace.gitlab.io/nazwa-projektu.