Una suite di test dovrebbe passare solo se tutti i test passano. Altrimenti, i test diventano inutili. Che cos'è un fallimento importante, che cos'è un errore che può essere ignorato? Il risultato sarebbe che tutti i fallimenti del test verrebbero ignorati dopo un po '. Bad.
C'è un'eccezione a questa: una suite di test può contenere test che notoriamente falliscono, poiché la funzionalità necessaria deve ancora essere implementata o il bug deve ancora essere corretto. Tali test sono preziosi perché documentano chiaramente un bug. Ma poiché il loro fallimento non sarebbe una regressione, il loro fallimento non dovrebbe fallire nell'intera suite di test (al contrario, se iniziano a passare ciò significherebbe che la tua suite di test non è aggiornata con il tuo codice). Idealmente, il tuo framework di test ha un concetto di tali "test TODO".
Le metriche di qualità sono una bestia diversa. Se una metrica di qualità supera una soglia, ciò indica che qualcosa è probabilmente ma non necessariamente maturo per un refactoring. Ma alcune "violazioni" potrebbero andare bene nel contesto di quel codice. Finché alcune regioni di codice possono essere escluse da specifici strumenti di analisi, la verifica di tale metrica di qualità è OK. Ovviamente, qualsiasi esclusione esplicita sarebbe una bandiera rossa in una revisione del codice e soggetta a un controllo più approfondito, ma mantenere un tale portello di fuga aperto per circostanze eccezionali è importante.
In particolare, l'idea di richiedere una qualità crescente come artefatto viaggia attraverso la pipeline di rilascio non è necessariamente buona. Da dove viene l'incremento qualitativo necessario? Dagli sviluppatori che migliorano il codice e reinviano un nuovo artefatto nella pipeline. Poiché la metrica di qualità necessaria per attraversare l'intera pipeline è conosciuta in anticipo, la presentazione di qualsiasi artefatto senza questa qualità è una perdita di tempo. Allora perché lo stai facendo? Probabilmente, le fasi della pipeline forniscono un feedback sul programma che è utile prima della versione principale. Per ottenere questo feedback, devi inviare il codice anche quando non hai intenzione di farlo attraverso la pipeline. Di nuovo, i falsi negativi sono cattivi. Tale flusso di lavoro non è adatto per un modello di pipeline e il feedback dovrebbe essere disponibile indipendentemente.
Questo non significa che dovresti rinunciare al gating di qualità. Ma se il tuo obiettivo è una metrica al 100% per un rilascio, la metrica di qualità corrente diventa un indicatore di progresso per il tuo progetto, come un grafico di burn down per il debito tecnico.