Continuous integration (integrazione continua)

Continuous integration (CI, integrazione continua) significa che gli sviluppatori uniscono frequentemente piccole modifiche nel branch principale, e un server compila il codice ed esegue i test automatizzati a ogni push o pull request. Lo scopo è un feedback rapido: se una modifica rompe qualcosa, l’autore lo scopre quando la modifica è ancora fresca, non giorni dopo durante un grosso merge.

Esempio (GitHub Actions)

Una pipeline minima che esegue la suite di test a ogni pull request e a ogni push su main:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Se npm test termina con un codice diverso da zero, il job fallisce e la pull request mostra un check rosso. Insieme a una branch protection che richiede questo check, il codice rotto non può essere unito.

Di cosa è responsabile un tester nella CI

• Quali test girano e dove. Test unitari e di API veloci a ogni pull request; suite end-to-end più lente al merge o su schedulazione. Una pipeline di pull request che dura 40 minuti smette di essere usata.
• Qualità del segnale. Un flaky test in un job bloccante abitua le persone a cliccare “re-run”. Metti in quarantena i test instabili, così che una build rossa significhi sempre qualcosa.
• Artefatti. Pubblica report, trace e screenshot delle esecuzioni fallite, così nessuno deve riprodurre un fallimento in locale solo per vederlo.
• Parallelismo. Suddividere (sharding) una suite lunga su più macchine mantiene costante il tempo di feedback man mano che la suite cresce.

Differenza rispetto alla CD

La continuous delivery estende la CI: ogni build che passa viene pacchettizzata e tenuta pronta per il rilascio, di solito passando per ambienti di staging. Il continuous deployment fa un passo in più e rilascia automaticamente in produzione ogni modifica che passa. La CI è la base di entrambi; senza una suite di test affidabile a ogni commit, nessuno dei due è sicuro.

Errori comuni

Eseguire la CI solo di notte, lasciare il branch principale rosso per giorni e trattare la pipeline come il luogo in cui si scrivono i test invece che quello in cui si eseguono. La CI è un’abitudine del team tanto quanto uno strumento: merge piccoli, e quando la build si rompe si corregge o si fa revert.