Quality gate

Un quality gate è un insieme di condizioni che una modifica deve soddisfare prima di passare alla fase successiva: merge, deploy in staging o rilascio in produzione. Ogni condizione è misurabile e verificata automaticamente e, se una fallisce, la pipeline si ferma. Il gate sostituisce il “a qualcuno sembra a posto” con un’asticella esplicita e concordata.

Condizioni tipiche di un gate

• Tutti i test bloccanti passano (unit, API, un sottoinsieme smoke dei test end-to-end).
• La coverage di righe o di branch sul codice nuovo non scende sotto un valore concordato.
• Nessun nuovo finding critico o alto dall’analisi statica o dalla scansione delle dipendenze.
• Le soglie di performance sono rispettate, ad esempio latenza p95 sotto i 500 ms in un breve test di carico.
• La build è riproducibile e l’artefatto è firmato o versionato.

Esempio

Un gate sulla coverage in Jest. Se la coverage scende sotto questi valori, jest --coverage termina con un codice diverso da zero e il job di CI fallisce:

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

Da solo, questo fa fallire soltanto un job. Diventa un gate quando il job è uno status check obbligatorio nella branch protection, così il pulsante di merge resta disabilitato finché non passa. Strumenti come SonarQube raggruppano più condizioni in un unico gate con nome e un solo risultato pass/fail.

Perché è importante

I gate rendono visibile e coerente la definizione di “pronto”. Spostano anche le discussioni al momento giusto: il team discute la soglia una volta, quando la stabilisce, invece che a ogni rilascio.

Errori comuni

• Gate su numeri facili da aggirare. Una regola rigida di coverage al 90% invita a scrivere test che eseguono codice senza verificare nulla. Metti il gate sulla coverage del codice nuovo e revisiona i test stessi.
• Controlli flaky nel gate. Un gate che fallisce a caso finisce per essere scavalcato. Lascia bloccanti solo i controlli deterministici; esegui gli altri come non bloccanti con alert.
• Troppi gate, troppo tardi. Dieci condizioni verificate solo prima del rilascio producono una montagna di fallimenti che nessuno ha il tempo di correggere. Metti i controlli economici all’inizio, su ogni pull request.
• Override silenziosi. Se un gate può essere saltato, registra chi l’ha saltato e perché.