CI Pipeline Automatica: Linting, Test Coverage e Build per Codice Senza Sorprese

Il tuo team committa codice, ma ogni volta la build si rompe perché qualcuno ha dimenticato una virgola o una parentesi? I test passano in locale ma in CI no? Il deployment è una roulette russa che tiene tutti col fiato sospeso? Questo è il problema che risolviamo ogni giorno con una CI pipeline ben strutturata. Noi, di Meteora Web, abbiamo visto progetti da migliaia di righe collassare per mancanza di linting, test coverage insufficiente e build manuali. Il costo? Ore perse, clienti scontenti e codice che diventa un groviglio. In questa guida operativa ti mostriamo come linting, test coverage e build automatici trasformano il caos in un processo prevedibile.

Perché linting, test e build automatici non sono un lusso

Immagina di dover fare il bilancio di un’azienda con un foglio Excel pieno di errori di sintassi. Sarebbe un disastro. Il codice è lo stesso: un errore di stile o una virgola fuori posto può rompere tutto. Il linting è il correttore ortografico del codice. I test coverage sono la verifica che ogni riga faccia ciò che deve. I build automatici trasformano il codice sorgente in un artefatto pronto per il deploy. Senza questi tre elementi, ogni commit è un rischio. Noi partiamo sempre da una domanda: quanto costa un bug in produzione? La risposta è quasi sempre molto più del tempo speso a impostare la pipeline.

Linting: la grammatica del codice

Il linting non è solo estetica. È il primo filtro che blocca errori banali, applica standard condivisi e riduce il debito tecnico. Noi usiamo ESLint per JavaScript e PHP CodeSniffer per PHP, integrandoli direttamente nella CI.

Come implementarlo in GitHub Actions

Ecco un esempio di workflow che esegue linting su ogni push e pull request:

name: Lint and Test
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Run ESLint
        run: npx eslint . --ext .js,.jsx

Attenzione: non fermarti al linting di base. Configura regole specifiche per il tuo stack. Noi, per i progetti Laravel, usiamo anche Laravel Pint. Se non trovi errori, il workflow passa. Se sì, la PR viene bloccata. Semplice, efficace.

Test coverage: non solo percentuale, ma qualità

Avere il 90% di coverage non serve se le parti critiche (autenticazione, pagamenti) sono scoperte. Il test coverage deve essere associato a metriche di qualità del codice. Noi utilizziamo PHPUnit per PHP e Vitest per Vue/JS, generando report XML che la CI può analizzare.

Impostare un minimo di coverage in CI

Con PHPUnit, puoi generare un report Clover e impostare una soglia minima:

  
    
  
  
    
      src
    
  

Poi in CI (es. con GitHub Actions e phpunit-coverage-check) controlliamo che la percentuale sia ≥ 80%. Se scende, la build fallisce. Questo obbliga il team a mantenere test vivi e aggiornati.

Build automatici: compilare, minificare, versionare

Il build è il passaggio dallo sviluppo al deploy. Noi automatizziamo tutto: compilazione SASS/SCSS, minificazione JS, generazione asset versionati, installazione dipendenze di produzione. Niente più script manuali dimenticati.

Esempio di build con Node.js e Laravel Mix

const mix = require('laravel-mix');
mix.js('resources/js/app.js', 'public/js')
   .sass('resources/sass/app.scss', 'public/css')
   .version();

In CI, basta eseguire npm run production per ottenere asset pronti. Noi includiamo anche un passaggio per ottimizzare le immagini con imagemin. Risultato: file più leggeri del 40-60%.

Integrare tutto in una CI pipeline

Un unico workflow che unisce linting, test e build. Ecco un esempio completo per GitHub Actions:

name: CI Pipeline
on: [push, pull_request]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Run tests with coverage
        run: npm run test:coverage
      - name: Check coverage threshold
        uses: verypossible/coverage-check@v1
        with:
          path: coverage/clover.xml
          threshold: 80
      - name: Build
        run: npm run production

Questo workflow blocca ogni push se anche un solo step fallisce. Il tempo medio di esecuzione? Meno di 3 minuti. Noi, di Meteora Web, abbiamo scelto questa architettura perché ci permette di fare deploy multipli al giorno senza paura.

Mettere in produzione con sicurezza

Una CI che produce artefatti puliti è la base per un deploy senza dolore. Approfondiamo questo aspetto nella nostra Guida Pillar DevOps e CI/CD. Lì trovi come collegare la CI al CD (Continuous Delivery) e rilasciare in produzione con un solo click.

In sintesi — cosa fare adesso

1. Imposta il linting nel tuo repository. Scegli uno strumento (ESLint, PHPCS) e configuralo con regole del team.
2. Scrivi test con coverage. Anche un piccolo test per ogni funzione critica. Punta ad almeno l’80% di copertura.
3. Automatizza il build. Compila e minifica gli asset con un unico comando.
4. Integra tutto in una CI. Usa GitHub Actions o GitLab CI per eseguire linting, test e build su ogni push.
5. Monitora i fallimenti. Non ignorare una build rossa. Ogni fallimento è un’opportunità per migliorare il codice.

Noi mettiamo in pratica questo processo ogni giorno, sui progetti dei nostri clienti. Il risultato? Meno bug, più velocità e un team che dorme sereno. Se vuoi implementare una CI pipeline solida, contattaci.