GitLab — baze, capabilități și CI/CD

Ce este GitLab?

GitLab — este o platformă DevOps completă cu sursă deschisă sub licența MIT. Spre deosebire de GitHub, care combină diverse servicii prin integrări, GitLab oferă un instrument unic pentru întregul ciclu de viață al dezvoltării: de la gestionarea codului și code review până la CI/CD, monitorizare, securitate și implementare. Platforma nu necesită servicii terțe pentru majoritatea sarcinilor DevOps.

Istoria GitLab a început în 2011 ca un proiect intern al dezvoltatorilor ucraineni. Prima versiune publică a fost lansată în septembrie 2011, iar în 2015 GitLab a devenit primul proiect pe GitLab.com, lansând hosting-ul cloud. În 2017, GitLab a efectuat un proces de migrare dureros, dar edificator — transferul întregii infrastructuri de la Azure la Google Cloud, care a fost transmis în direct și documentat într-o serie de articole.

Arhitectura GitLab constă din trei componente principale: GitLab Rails (aplicație web în Ruby on Rails), GitLab Shell (procesarea operațiunilor Git prin SSH) și Gitaly (server gRPC pentru accesul la datele Git). CI/CD este asigurat de GitLab Runner — o aplicație separată care se instalează pe serverele de build și execută job-uri în medii izolate (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipeline-uri și runneri

GitLab CI/CD — este un sistem integrat de integrare și livrare continuă, care reprezintă un avantaj cheie al platformei. Spre deosebire de GitHub Actions, GitLab CI/CD a fost încorporat în arhitectură de la bun început și nu necesită o configurare separată: fiecare proiect primește automat CI/CD după adăugarea fișierului .gitlab-ci.yml în rădăcina repository-ului.

Pipeline-ul (pipeline) constă în etape (stages) care se execută secvențial sau paralel: build → test → deploy. Fiecare etapă conține unul sau mai multe job-uri care se execută pe runneri. Dacă un job dintr-o etapă se termină cu eroare, întreaga etapă este marcată ca failed, iar etapele următoare nu se lansează implicit. Mai jos este un exemplu de pipeline pentru un proiect mobil:

# .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 suportă mai mulți executor (executanți): Docker (recomandat), Kubernetes, SSH, VirtualBox și Parallels. Cea mai populară opțiune este executantul Docker, care rulează fiecare job într-un container separat. Runner-ul poate fi înregistrat ca specific unui proiect sau ca partajat (shared) pentru întreaga grupă. GitLab.com oferă runneri partajați gratuit, cu o limită de 2000 de minute pe lună.

Capabilități avansate CI/CD

GitLab CI/CD suportă lansarea manuală (when: manual), lansarea întârziată (when: delayed), executarea paralelă (parallel: 5), matricea (matrix), pipeline-uri dinamice (child pipelines) și pipeline-uri multinivel (parent-child). Acest lucru permite construirea de scenarii complexe: de exemplu, generarea dinamică a unui pipeline pentru fiecare modul într-un monorepository sau lansarea de build-uri paralele pentru diferite arhitecturi Android (arm64, x86_64).

GitLab vs GitHub: diferențe cheie

GitLab și GitHub — cei doi competitori principali pe piața platformelor Git, dar filosofia și arhitectura lor diferă fundamental. GitHub pune accent pe comunitatea deschisă, ecosistemul de integrări și funcțiile sociale (fork-uri, stele). GitLab se concentrează pe ciclul DevOps complex și oferă toate instrumentele din cutie: de la planificare la monitorizare.

Diferența arhitecturală principală: GitLab — este o aplicație monolitică unică pe care dezvoltatorul o instalează în totalitate. Toate funcțiile (CI/CD, Container Registry, Security Scanning, Pages) sunt integrate și funcționează imediat după instalare. GitHub — este o platformă cu API, unde majoritatea funcțiilor sunt realizate prin integrarea cu servicii terțe: Travis CI, CircleCI, Jenkins, SonarQube. Tabelul de mai jos compară caracteristicile cheie:

Alegerea între GitLab și GitHub depinde de nevoile echipei. Dacă prioritatea este implementarea rapidă cu configurare zero și comunitatea deschisă — alegeți GitHub. Dacă este necesară gestionarea completă a infrastructurii, hosting-ul propriu și securitatea integrată — GitLab este de preferat. Potrivit sondajului Stack Overflow (2024), 90% dintre dezvoltatori folosesc GitHub, 33% — GitLab (adesea ambele platforme simultan).

Self-Managed GitLab: instalare pe propriul server

Self-Managed GitLab (anterior On-Premises) permite instalarea platformei pe propriul server și obținerea controlului complet asupra datelor, infrastructurii și disponibilității. Acest lucru este deosebit de important pentru organizațiile cu cerințe de conformitate: sectorul financiar, instituțiile guvernamentale, organizațiile medicale, unde datele nu pot fi stocate pe servere terțe.

Instalarea GitLab este suportată pe Ubuntu, Debian, CentOS și prin Docker. Pachetul oficial Omnibus include toate componentele: server web (NGINX), bază de date (PostgreSQL), cache (Redis), procesor Git (Gitaly) și procese de fond. Cerințe minime: 4 GB RAM și 2 CPU pentru o echipă de până la 100 de persoane. Pentru instalații mari cu sarcină ridicată, se recomandă separarea componentelor pe servere separate.

# Instalarea GitLab CE pe Ubuntu prin Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

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

# Vizualizarea stării
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab nu are limită de minute CI/CD — toți runnerii aparțin organizației, iar puterea lor este limitată doar de propriul hardware. De asemenea, sunt disponibile Geo-replicarea pentru regiuni, jurnalele de audit, blocarea IP și integrarea cu furnizorii corporate LDAP/SAML. GitLab lansează actualizări lunar (pe 22) cu funcții noi și corecturi de securitate.

Instrumente de securitate integrate GitLab

Securitatea în GitLab este integrată la nivel de platformă și include mai mulți scanere care lucrează la fiecare etapă a pipeline-ului. SAST (Static Application Security Testing) analizează codul sursă pentru vulnerabilități fără a executa aplicația, suportând peste 15 limbi, inclusiv Java, Kotlin, Swift, Python și JavaScript. DAST (Dynamic Application Security Testing) testează aplicația web în execuție pentru vulnerabilități din interior.

Instrumente suplimentare: Container Scanning verifică imaginile Docker pentru vulnerabilități în straturile de bază; Dependency Scanning analizează dependențele proiectului și avertizează despre CVE-uri cunoscute; Secret Detection găsește chei API, parole și token-uri comise accidental; Fuzz Testing execută testare automată cu date incorecte pentru a găsi bug-uri neevidente. Toate rezultatele scanării sunt afișate într-un Security Dashboard unic.

GitLab oferă, de asemenea, Compliance — instrumente pentru respectarea cerințelor de reglementare. Compliance Dashboard arată starea de conformitate a tuturor proiectelor, Audit Events înregistrează fiecare acțiune a administratorului și dezvoltatorului, iar Compliance Frameworks permit aplicarea forțată a politicilor de configurare pentru anumite grupuri de proiecte. Acest lucru face din GitLab o alegere populară în mediile corporative cu cerințe stricte de securitate.

Container Registry și Dependency Proxy

GitLab Container Registry — este un registru Docker integrat, conectat cu CI/CD. După construirea imaginii Docker în pipeline, aceasta poate fi publicată imediat în Registry folosind variabilele de mediu CI_REGISTRY și CI_REGISTRY_USER. Registry suportă cache-ul pull-through, etichetarea, politicile de curățare și scanarea vulnerabilităților direct în registru.

Dependency Proxy — un mecanism de cache pentru containere și imagini din registre externe (Docker Hub, Quay, GCR). Când pipeline-ul solicită imaginea ubuntu:latest, GitLab verifică mai întâi propriul cache — dacă imaginea a fost deja încărcată, nu este descărcată din nou. Aceasta reduce sarcina asupra registrelor externe, accelerează pipeline-urile și protejează împotriva limitelor de rată ale Docker Hub.

Pentru dezvoltatorii mobili, GitLab oferă GitLab Pages pentru hostingul documentației și rapoartelor de testare. După rularea testelor, artefactele (rapoarte HTML, capturi de ecran, loguri) pot fi publicate ca Pages și se poate obține un link pentru trimiterea echipei QA. Acest lucru este mai comod decât încărcarea rapoartelor în stocarea cloud, deoarece totul este plasat în cadrul aceluiași proiect GitLab.

API GitLab și Webhook-uri

GitLab API (REST și GraphQL) oferă acces la toate resursele platformei: proiecte, utilizatori, pipeline-uri, Merge Request, registru. API-ul este utilizat pentru automatizare: crearea unui proiect din șablon, desemnarea unui revizor, obținerea stării pipeline-ului. Webhook-urile permit trimiterea de notificări HTTP către sisteme externe la evenimente: push, merge, crearea Issue. Webhook-urile se integrează cu Mattermost, Slack, Telegram și sistemele interne de monitorizare.

GitLab Pages pentru documentație mobilă

GitLab Pages publică automat site-uri statice din repository. Pentru proiectele mobile, Pages este util pentru amplasarea documentației API, rapoartelor de acoperire a testelor și rezultatelor analizei lint. Publicarea are loc automat după un pipeline de succes — este suficient să specificați în .gitlab-ci.yml pasul deploy cu publicarea în Pages. Rezultatul este disponibil la adresa https://namespace.gitlab.io/nume-proiect.