Vai al contenuto principale

DevOps con gli strumenti di GitLab: il percorso di una Gilda

6 Ottobre 2025 - 3 minuti di lettura

In questo articolo vi racconto il percorso di studio e pratica intrapreso durante gli incontri della Gilda DevOps Heroes: dalla configurazione di un’istanza self-hosted su Docker, fino alla creazione di pipeline reali che hanno permesso di applicare concetti di CI/CD in scenari concreti.

Un’esperienza formativa che ha unito teoria, esercitazioni e confronto diretto tra colleghi, rafforzando competenze e consapevolezza sui vantaggi dell’approccio DevOps.

Implementare metodologie DevOps con gli strumenti integrati di GitLab

Nel contesto attuale dello sviluppo software, è fondamentale adottare modalità strutturate ed efficienti per rilasciare applicazioni e aggiornamenti in produzione.
L’approccio DevOps nasce proprio con l’obiettivo di colmare il divario tra sviluppo (Dev) e operations (Ops), favorendo automazione, integrazione continua e una collaborazione più fluida tra team.

Per la Gilda DevOps Heroes, i colleghi più esperti hanno proposto GitLab come strumento ideale per dimostrare l’efficacia del metodo DevOps nel rilascio del codice. La scelta si basa sia sull’esperienza diretta dei membri con la piattaforma, sia sul fatto che GitLab si presenti come una soluzione all-in-one, capace di coprire l’intero ciclo di vita del software: dalla scrittura del codice al deploy in produzione, passando per il controllo versione, la CI/CD e il monitoraggio delle pipeline.

Un GitLab self-hosted su Docker

Per le prime sessioni di studio abbiamo configurato un’istanza self-hosted di GitLab all’interno di un container Docker. Lavorare con macchine virtuali e container rappresenta infatti una competenza fondamentale per ogni specialista IT/DevOps. Questo approccio, rispetto all’utilizzo di un GitLab preconfigurato, presenta vantaggi e svantaggi. Tra i punti di forza, la possibilità di sperimentare liberamente senza preoccuparsi di gruppi di appartenenza o permessi, con la facoltà di resettare e riconfigurare l’ambiente senza rischiare di interferire con le normali attività di produzione. D’altro canto, l’immagine Docker scelta ha richiesto diverse personalizzazioni per adattarsi alle nostre esigenze: un’attività formativa, ma anche impegnativa e causa di alcune interruzioni nello studio di GitLab.

Teoria e pratica con GitLab

Le sessioni si sono svolte alternando teoria e pratica, così da mantenere un equilibrio e non limitarsi a un approccio puramente accademico. Per la parte teorica ci siamo affidati direttamente alle risorse ufficiali di GitLab University, che offrono corsi gratuiti con una panoramica completa sulle tecnologie disponibili e quiz utili per fissare i concetti chiave dell’ecosistema GitLab. Nonostante la loro validità, questi corsi non sempre sono riusciti a mantenere alta l’attenzione: in questo ci hanno supportato le esercitazioni pratiche, gli hands-on lab e soprattutto la competenza di alcuni membri unita all’entusiasmo degli altri.

Sul piano pratico, abbiamo costruito semplici pipeline intorno a del codice, esercizio che ci ha permesso di mettere in pratica i concetti appresi in scenari “realistici”. Questa parte si è rivelata stimolante e formativa, anche perché qualcuno ha colto l’occasione per sperimentare linguaggi di programmazione che non utilizza abitualmente.

Cosa abbiamo imparato

Verso la conclusione della Gilda, abbiamo raggiunto una solida comprensione dei principi del DevOps e una buona padronanza dell’ecosistema che GitLab ha sviluppato intorno a questa metodologia.
I concetti approfonditi includono:

    • Pipeline: un processo automatizzato che esegue una sequenza di stage, ciascuno composto da diversi job.
      • Esempi di stage comuni: build, test, deploy, review, staging, production.
  • CI (Continuous Integration): la pratica di aggiornare il codice con frequenza, anche più volte al giorno, da parte di uno o più sviluppatori.
    Nelle pipeline di GitLab, ogni push viene testato per individuare tempestivamente bug o regressioni.
  • CD (Continuous Delivery): il naturale completamento della CI.
    L’obiettivo è mantenere il codice sempre in uno stato pronto per la produzione.
    GitLab può generare automaticamente pacchetti rilasciabili una volta superati i test della CI.

I seguenti concetti si riferiscono in particolare a GitLab CI/CD:

  • Le pipeline vengono definite tramite un file YAML chiamato .gitlab-ci.yml, che specifica stage, job, ordine di esecuzione, variabili e condizioni.
  • GitLab Runner: un agente che esegue i job definiti nel file .gitlab-ci.yml. Ogni job viene eseguito in un ambiente isolato.
    I processi di automazione possono essere resi dinamici utilizzando variabili d’ambiente configurate nel file o direttamente nelle impostazioni di GitLab.
Articolo scritto da