GitLab — fondamenti, funzionalità e CI/CD

Cos'è GitLab?

GitLab — è una piattaforma DevOps open source completa con licenza MIT. A differenza di GitHub, che combina vari servizi tramite integrazioni, GitLab fornisce un unico strumento per l'intero ciclo di vita dello sviluppo: dalla gestione del codice e la revisione del codice al CI/CD, monitoraggio, sicurezza e distribuzione. La piattaforma non richiede servizi di terze parti per la maggior parte delle attività DevOps.

La storia di GitLab è iniziata nel 2011 come progetto interno di sviluppatori ucraini. La prima versione pubblica è uscita nel settembre 2011, e nel 2015 GitLab è diventato il primo progetto su GitLab.com, lanciando l'hosting cloud. Nel 2017, GitLab ha eseguito un processo di migrazione doloroso ma istruttivo — il trasferimento dell'intera infrastruttura da Azure a Google Cloud, condotto in diretta e documentato in una serie di post.

L'architettura di GitLab è composta da tre componenti principali: GitLab Rails (applicazione web su Ruby on Rails), GitLab Shell (gestione delle operazioni Git via SSH) e Gitaly (server gRPC per l'accesso ai dati Git). Il CI/CD è fornito da GitLab Runner — un'applicazione separata installata sui server di build che esegue job in ambienti isolati (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipeline e runner

GitLab CI/CD — è un sistema integrato di integrazione e distribuzione continue che rappresenta un vantaggio chiave della piattaforma. A differenza di GitHub Actions, GitLab CI/CD è stato integrato nell'architettura fin dall'inizio e non richiede configurazione separata: ogni progetto ottiene automaticamente CI/CD dopo l'aggiunta del file .gitlab-ci.yml nella radice del repository.

Una pipeline è composta da fasi eseguite in sequenza o in parallelo: build → test → deploy. Ogni fase contiene uno o più job eseguiti sui runner. Se un job in una fase fallisce, l'intera fase viene contrassegnata come fallita e le fasi successive non vengono eseguite per impostazione predefinita. Di seguito è riportato un esempio di pipeline per un progetto mobile:

# .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 supporta diversi esecutori: Docker (consigliato), Kubernetes, SSH, VirtualBox e Parallels. L'opzione più popolare è l'esecutore Docker, che esegue ogni job in un contenitore separato. Un runner può essere registrato come specifico per un progetto o come condiviso (shared) per un intero gruppo. GitLab.com fornisce runner condivisi gratuiti con un limite di 2000 minuti al mese.

Funzionalità avanzate di CI/CD

GitLab CI/CD supporta l'attivazione manuale (when: manual), l'attivazione ritardata (when: delayed), l'esecuzione parallela (parallel: 5), la matrice, pipeline dinamiche (child pipelines) e pipeline multilivello (parent-child). Ciò consente di creare scenari complessi: ad esempio, generare dinamicamente una pipeline per ogni modulo in un monorepo o eseguire build parallele per diverse architetture Android (arm64, x86_64).

GitLab vs GitHub: differenze principali

GitLab e GitHub — sono i due principali concorrenti nel mercato delle piattaforme Git, ma la loro filosofia e architettura differiscono radicalmente. GitHub punta sulla comunità aperta, un ecosistema di integrazioni e funzionalità social (fork, stelle). GitLab si concentra su un ciclo DevOps completo e fornisce tutti gli strumenti pronti all'uso: dalla pianificazione al monitoraggio.

La principale differenza architetturale: GitLab — è un'unica applicazione monolitica che lo sviluppatore installa per intero. Tutte le funzionalità (CI/CD, Container Registry, Security Scanning, Pages) sono integrate e funzionano subito dopo l'installazione. GitHub è una piattaforma con API dove la maggior parte delle funzionalità è implementata tramite integrazione con servizi di terze parti: Travis CI, CircleCI, Jenkins, SonarQube. La tabella seguente confronta le caratteristiche principali:

La scelta tra GitLab e GitHub dipende dalle esigenze del team. Se la priorità è una distribuzione rapida con configurazione zero e una comunità aperta — scegli GitHub. Se hai bisogno di controllo completo sull'infrastruttura, hosting auto-gestito e sicurezza integrata — GitLab è preferibile. Secondo un sondaggio di Stack Overflow (2024), il 90% degli sviluppatori usa GitHub, il 33% usa GitLab (spesso entrambe le piattaforme contemporaneamente).

Self-Managed GitLab: installazione sul proprio server

Self-Managed GitLab (precedentemente On-Premises) consente di installare la piattaforma sul proprio server e avere il controllo completo su dati, infrastruttura e uptime. Questo è particolarmente importante per le organizzazioni con requisiti di conformità: settore finanziario, istituzioni governative, organizzazioni mediche dove i dati non possono essere archiviati su server di terze parti.

L'installazione di GitLab è supportata su Ubuntu, Debian, CentOS e tramite Docker. Il pacchetto ufficiale Omnibus include tutti i componenti: server web (NGINX), database (PostgreSQL), cache (Redis), gestore Git (Gitaly) e processi in background. Requisiti minimi: 4 GB di RAM e 2 CPU per team fino a 100 persone. Per installazioni grandi con carico elevato, si consiglia di separare i componenti su server distinti.

# Installare GitLab CE su Ubuntu tramite Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Installazione del pacchetto
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Visualizzazione dello stato
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab non ha limiti di minuti CI/CD — tutti i runner appartengono all'organizzazione e la loro potenza è limitata solo dal proprio hardware. Sono inoltre disponibili Geo-replicazione per le regioni, log di audit, blocco IP e integrazione con provider LDAP/SAML aziendali. GitLab pubblica aggiornamenti ogni mese (il 22) con nuove funzionalità e correzioni di sicurezza.

Strumenti di sicurezza integrati di GitLab

La sicurezza in GitLab è integrata a livello di piattaforma e include diversi scanner che operano in ogni fase della pipeline. SAST (Static Application Security Testing) analizza il codice sorgente alla ricerca di vulnerabilità senza eseguire l'applicazione, supportando oltre 15 linguaggi tra cui Java, Kotlin, Swift, Python e JavaScript. DAST (Dynamic Application Security Testing) testa le applicazioni web in esecuzione alla ricerca di vulnerabilità dall'interno.

Strumenti aggiuntivi: Container Scanning controlla le immagini Docker per vulnerabilità negli strati di base; Dependency Scanning analizza le dipendenze del progetto e avverte su CVE note; Secret Detection trova chiavi API, password e token accidentalmente commitati; Fuzz Testing esegue test automatizzati con dati malformati per trovare bug non evidenti. Tutti i risultati di scansione vengono visualizzati in un Security Dashboard unificato.

GitLab fornisce anche strumenti di Conformità per soddisfare i requisiti normativi. Il Compliance Dashboard mostra lo stato di conformità di tutti i progetti, Audit Events registra ogni azione di amministratori e sviluppatori, e Compliance Frameworks consente di applicare obbligatoriamente politiche di configurazione per gruppi specifici di progetti. Questo rende GitLab una scelta popolare in ambienti aziendali con rigorosi requisiti di sicurezza.

Registro contenitori e Dependency Proxy

GitLab Container Registry — è un registro Docker integrato con CI/CD. Dopo aver creato un'immagine Docker in una pipeline, può essere immediatamente pubblicata nel Registry utilizzando le variabili d'ambiente CI_REGISTRY e CI_REGISTRY_USER. Il Registry supporta la cache pull-through, l'etichettatura, le politiche di pulizia e la scansione delle vulnerabilità direttamente nel registro.

Dependency Proxy — un meccanismo di caching per contenitori e immagini da registri esterni (Docker Hub, Quay, GCR). Quando una pipeline richiede un'immagine come ubuntu:latest, GitLab controlla prima la sua cache — se l'immagine è già stata scaricata, non viene recuperata di nuovo. Questo riduce il carico sui registri esterni, accelera le pipeline e protegge dai limiti di velocità di Docker Hub.

Per gli sviluppatori mobili, GitLab fornisce GitLab Pages per ospitare documentazione e report di test. Dopo l'esecuzione dei test, gli artefatti (report HTML, screenshot, log) possono essere pubblicati come Pages e un link può essere condiviso con il team QA. Questo è più conveniente che caricare i report su storage cloud poiché tutto risiede all'interno dello stesso progetto GitLab.

API GitLab e Webhook

L'API GitLab (REST e GraphQL) fornisce accesso a tutte le risorse della piattaforma: progetti, utenti, pipeline, Merge Request, registro. L'API è utilizzata per l'automazione: creare un progetto da un modello, assegnare un revisore, ottenere lo stato della pipeline. I Webhook consentono di inviare notifiche HTTP a sistemi esterni su eventi: push, merge, creazione di Issue. I Webhook si integrano con Mattermost, Slack, Telegram e sistemi di monitoraggio interni.

GitLab Pages per la documentazione mobile

GitLab Pages pubblica automaticamente siti web statici da un repository. Per i progetti mobili, Pages è utile per ospitare documentazione API, report di copertura dei test e risultati di analisi lint. La pubblicazione avviene automaticamente dopo una pipeline riuscita — basta aggiungere un passaggio di deploy con pubblicazione su Pages. Il risultato è disponibile all'indirizzo https://namespace.gitlab.io/project-name.