Quanto breve / stabile dovrebbe essere il test / la build per la pipeline funzionante di CI / CD?

1

( Si noti che questa domanda è collegata a questo: In che modo la consegna continua funziona in pratica? - ma richiede una domanda più specifica su tempo e stabilità ).

CI / CD , nessun QA manuale , super-veloci sono le nuove parole d'ordine e ho letto su questo argomento molte volte, ma suona in qualche modo non realistico per i casi in cui i test automatici sono difficili da estrarre. Immagina un complesso software basato sull'interfaccia utente come un software di editing video. O uno che ha un backend enorme, un frontend enorme con setup di account complessi, diversi tipi di autenticazione, ecc. Ecc. O se le animazioni sono una parte enorme del tuo progetto frontend.

Per queste grandi applicazioni i test possono durare ore ( per darti una prospettiva: in uno dei nostri progetti sono stati eseguiti test dell'interfaccia utente completi per 16 ore su una sola piattaforma, coprendo solo il 50% di casi di test manuali ); anche i test dell'interfaccia utente sono notoriamente fragili (anche con un investimento molto pesante sulla loro stabilizzazione) e non si desidera assolutamente che il proprio rilascio venga ripristinato dopo 15 ore a causa di un bug casuale non riproducibile del test dell'interfaccia utente.

Quindi, la domanda è: quanto dovrebbe essere breve e stabile il build / test per poter estrarre una pipeline funzionante di CI / CD?

    
posta atoth 12.04.2016 - 11:26
fonte

2 risposte

8

In genere si hanno più pipeline - si eseguono test unitari "veloci e sporchi" mentre gli sviluppatori commettono modifiche. Quando dicono di essere pronti a unire le loro modifiche in un ramo di test, esegui test di integrazione più "lenti e costanti" (e qualsiasi altro strumento di analisi che ti piace). Se passano, unisci il ramo di test su un ramo QA da dove puoi generare consegne.

Questa pipeline a 3 stadi ti offre tutto ciò di cui hai bisogno: una verifica rapida e una qualità inferiore. Non puoi saltare i controlli di qualità, non importa cosa dice la buzzword du jour, dopotutto l'opinione di internet è di solito sbagliata.

In breve: fai ciò che conta per te, se vuoi le pubblicazioni di qualità, devi prendere il tempo per assicurarti che le pubblicazioni siano buone.

    
risposta data 12.04.2016 - 11:32
fonte
1

Separerei la stabilità del test dalla durata del test, sono importanti in diversi modi.

La stabilità del test è fondamentale se il test viene eseguito raramente e non ci sono abbastanza datapoint per misurare effettivamente la stabilità. Checken e problema alle uova.

Ma se esistono sufficienti datapoint di esecuzione per consentire una stima della stabilità del test, allora possono essere incorporati nella configurazione della pipeline CI / CD in modo tale che l'effetto di glitch occasionali sia ridotto, forse anche significativamente. Ad esempio, il test automatico (o manuale, dopo l'analisi umana) riprova prima di ripristinare il rilascio nel caso che hai menzionato, se il rispettivo test è noto per casualmente fallire abbastanza spesso. Il numero e la tempistica dei tentativi dipenderebbero dal tasso stimato di guasti casuali.

Un sistema CI / CD intelligente può includere il monitoraggio dei tassi di errore della verifica della qualità e persino aiutare a identificare i problemi intermittenti, o almeno i più dannosi.

Per quanto riguarda la durata del test - questo non è veramente rilevante. Nella stragrande maggioranza dei casi la suddivisione di un test molto lungo in più test più brevi che possono essere eseguiti in parallelo è una tecnica tipica per abbreviare l'esecuzione di una pipeline CI / CD (ad un prezzo, ovviamente).

    
risposta data 12.04.2016 - 22:20
fonte

Leggi altre domande sui tag