GitHub Actions vs GitLab CI: differenze e quale scegliere

Sono i due sistemi di integrazione continua più diffusi, fanno sostanzialmente le stesse cose, e la scelta tra loro è quasi sempre già decisa da un'altra scelta fatta prima. In questo articolo trovi cosa cambia davvero nell'uso quotidiano — al di là delle tabelle comparative — e i due o tre casi in cui la differenza pesa.

La premessa che decide quasi tutto

Entrambi funzionano solo sulla piattaforma di cui fanno parte. GitHub Actions richiede che il codice stia su GitHub, GitLab CI che stia su GitLab.

Questo significa che nella stragrande maggioranza dei casi non stai scegliendo il sistema di CI: stai usando quello della piattaforma che hai già scelto — e quella scelta si fa con criteri diversi, che ho messo in GitHub vs GitLab vs Bitbucket.

La domanda ha senso davvero in due situazioni: stai decidendo la piattaforma da zero, oppure stai valutando se le esigenze di automazione siano un motivo sufficiente per spostarti.

Come si configurano

La differenza più visibile.

GitHub Actions usa più file dentro .github/workflows/, uno per processo:

name: Test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

GitLab CI usa un unico file .gitlab-ci.yml nella radice, organizzato in fasi:

stages:
  - test
  - build

test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test

Le due filosofie:

GitHub è componibile: il valore sta nel catalogo enorme di componenti riutilizzabili (uses:) scritti dalla comunità. Assembli pezzi già pronti.

GitLab è dichiarativo: descrivi le fasi e i comandi, con meno dipendenza da componenti esterni. Più esplicito, meno assemblaggio.

Nell'uso quotidiano, la differenza pratica è questa: su GitHub trovi quasi sempre un'azione già fatta per quello che ti serve; su GitLab scrivi tu i comandi, ma sai esattamente cosa fanno.

Dove GitLab è più forte

L'esecuzione su infrastruttura propria. Puoi installare gli esecutori sui tuoi server, gratuitamente, senza limiti di minuti. È il vantaggio decisivo per chi ha vincoli sui dati o volumi di build molto alti.

Le fasi native. Il concetto di sequenza — test, poi build, poi deploy — è integrato nel modello. Su GitHub si ottiene lo stesso con le dipendenze tra job, ma è meno immediato da leggere.

Il ciclo di rilascio integrato. Ambienti, distribuzioni, possibilità di annullare un rilascio: sono parte del prodotto, non funzioni da assemblare.

Un unico file. Su progetti medi è più facile avere il quadro completo in un colpo d'occhio.

Dove GitHub è più forte

Il catalogo di azioni. È il vantaggio più concreto e quello che si sente ogni giorno: qualunque cosa ti serva — configurare un linguaggio, pubblicare su una piattaforma, gestire una cache — esiste già ed è mantenuta.

L'ecosistema. Ogni servizio esterno ha la sua azione ufficiale pronta all'uso.

La documentazione e la comunità. Un problema che incontri lo ha già incontrato qualcun altro, e la risposta è cercabile.

L'integrazione con le proposte di modifica, che è dove si consuma la maggior parte del valore dell'integrazione continua.

Il quadro completo è in cosa sono le GitHub Actions.

Il confronto

	GitHub Actions	GitLab CI
Configurazione	Più file in una cartella	Un file unico
Filosofia	Componenti riutilizzabili	Comandi espliciti
Catalogo pronto	Enorme	Limitato
Fasi sequenziali	Via dipendenze	Native
Esecutori propri	Possibile	Gratuito e naturale
Self-hosting completo	A pagamento	Gratuito
Comunità	Molto ampia	Media

I costi

Il modello è simile e il ragionamento pratico pure.

Entrambi offrono minuti gratuiti sui piani base e fatturano a consumo oltre soglia. Entrambi hanno moltiplicatori sui sistemi non Linux — macOS in particolare costa molto di più.

Le leve per contenere la spesa sono le stesse:

• Usa Linux dove possibile
• Metti in cache le dipendenze invece di reinstallarle a ogni esecuzione
• Filtra per percorso: non rilanciare tutto se hai modificato solo il README
• Annulla le esecuzioni superate quando arriva un nuovo invio

Su GitLab c'è una via d'uscita in più: con esecutori propri, i minuti non si contano. Su volumi alti la differenza economica diventa sostanziale, a fronte del costo di gestire quell'infrastruttura — e su un monorepo, dove ogni modifica rischia di far ripartire tutto, il filtro per percorso conta ancora di più.

Il criterio di scelta

In ordine:

1. Dove sta già il codice? Nel 90% dei casi la risposta chiude la questione.

2. Il codice può stare su un servizio esterno? Se no, GitLab self-hosted è praticamente obbligato — ed è la ragione più solida per scegliere quella strada.

3. Fate build pesantissime? Con esecutori propri su GitLab il costo dei minuti sparisce.

4. Nessuno dei precedenti? GitHub, per l'ecosistema.

Per un progetto personale o un team piccolo senza vincoli particolari, GitHub Actions è la scelta di default sensata — non perché sia tecnicamente superiore, ma perché trovi già pronto quasi tutto quello che ti serve.

Una nota sulla portabilità

Vale la pena tenerne conto in fase di progetto: le configurazioni non sono compatibili. Passare da un sistema all'altro significa riscrivere i processi.

Il modo di ridurre il vincolo è semplice e sottovalutato: metti la logica negli script, non nel file di configurazione.

# invece di dieci comandi nel file CI
script:
  - ./scripts/test.sh
  - ./scripts/build.sh

Così il file del sistema di CI si limita a dire quando eseguire qualcosa, e il cosa vive in script che funzionano ovunque — inclusa la tua macchina. Ha anche il vantaggio pratico di poter provare in locale quello che gira in automatico, senza il ciclo "modifica, invia, aspetta, sbagliato, riprova".

In sintesi

GitHub Actions e GitLab CI fanno le stesse cose e sono entrambi maturi. La differenza di configurazione è visibile — più file componibili contro un file unico dichiarativo — ma incide poco sul risultato.

GitLab vince su esecutori propri gratuiti e self-hosting completo; GitHub vince sul catalogo di componenti già pronti, che nell'uso quotidiano è il vantaggio più tangibile.

Ma la scelta è quasi sempre già decisa da dove sta il codice. Le due domande che contano davvero sono: il codice può uscire dall'azienda, e fate build così pesanti da voler eliminare il conteggio dei minuti.

E l'accorgimento che vale in entrambi i casi: tieni la logica negli script, non nel file di configurazione. Riduce il vincolo alla piattaforma e ti permette di provare in locale.