In che modo la consegna continua funziona in pratica?

22

La consegna continua sembra buona, ma i miei anni di esperienza nello sviluppo del software suggeriscono che in pratica non può funzionare.

(Modifica: per chiarire, ho sempre un sacco di test in esecuzione automatica.La mia domanda è su come ottenere la fiducia per fornire su ogni controllo, che capisco è la forma completa di CD. L'alternativa non è l'anno Cicli lunghi: si tratta di iterazioni settimanali (che alcuni potrebbero considerare ancora CD se eseguite correttamente), di due settimane o di un mese, incluso un QA vecchio stile alla fine di ognuna, che integra i test automatizzati.)

  • La copertura completa del test è impossibile. Devi mettere un sacco di tempo - e il tempo è denaro - per ogni piccola cosa. Questo è prezioso, ma il tempo potrebbe essere speso contribuendo alla qualità in altri modi.
  • Alcune cose sono difficili da testare automaticamente. Per esempio. GUI. Perfino il selenio non ti dirà se la tua interfaccia grafica è instabile. L'accesso al database è difficile da testare senza fixture ingombranti, e anche questo non coprirà casi angusti strani nella tua memoria dati. Allo stesso modo sicurezza e molte altre cose. Solo il codice del livello aziendale è effettivamente unità testabile.
  • Anche nel livello aziendale, la maggior parte del codice non è semplice funzioni i cui argomenti e valori di ritorno possono essere facilmente isolati per scopi di test. Puoi passare molto tempo a costruire oggetti fittizi, che potrebbero non corrispondere alle reali implementazioni.
  • I test di integrazione / test funzionali integrano i test unitari, ma questi richiedono molto tempo per essere eseguiti poiché di solito implicano la reinizializzazione dell'intero sistema in ogni test. (Se non si reinizializza, l'ambiente di test è incoerente.)
  • Il refactoring o qualsiasi altra modifica interrompono molti test. Passi molto tempo a risolverli. Se si tratta di convalidare modifiche significative delle specifiche, va bene, ma spesso i test si interrompono a causa di dettagli di implementazione di basso livello privi di significato, non di roba che fornisce realmente informazioni importanti. Spesso i tweaking si concentrano sulla rielaborazione degli interni del test, non sul vero controllo della funzionalità che viene testata.
  • I rapporti sul campo relativi ai bug non possono essere facilmente abbinati alla precisa versione micro del codice.
posta Joshua Fox 09.12.2011 - 12:57
fonte

6 risposte

28

my years of software development experience suggest that in practice it can't work.

L'hai provato? Dave e io abbiamo scritto il libro sulla base di molti anni di esperienza collettiva, sia di noi stessi che di altre persone senior in ThoughtWorks, facendo effettivamente le cose di cui discutiamo. Niente nel libro è speculativo. Tutto ciò di cui discutiamo è stato provato e testato anche su progetti grandi e distribuiti. Ma non ti suggeriamo di prenderlo sulla fede. Ovviamente dovresti provare tu stesso, e per favore scrivi ciò che trovi funziona e cosa no, incluso il contesto pertinente, in modo che gli altri possano imparare dalle tue esperienze.

La consegna continua ha un grande focus sui test automatici. Passiamo circa 1/3 del libro a parlarne. Lo facciamo perché l'alternativa - test manuale - è costosa e soggetta a errori, e in realtà non è un ottimo modo per creare software di alta qualità (come ha detto Deming, "Cessare la dipendenza dall'ispezione di massa per ottenere la qualità. il prodotto in primo luogo ")

Full test coverage is impossible. You have to put in lots of time -- and time is money -- for every little thing. This is valuable, but the time could be spent contributing to quality in other ways.

Ovviamente la copertura completa del test è impossibile, ma qual è l'alternativa: copertura del test zero? C'è un compromesso. In mezzo c'è una risposta corretta per il tuo progetto. Troviamo che in generale dovresti aspettarti di dedicare circa il 50% del tuo tempo alla creazione o al mantenimento di test automatizzati. Potrebbe sembrare costoso finché non consideri il costo di un test manuale completo e di correggere i bug che arrivano agli utenti.

Some things are hard to test automatically. E.g. GUI. Even Selenium won't tell you if your GUI is wonky.

Naturalmente. Controlla il quadrante del test di Brian Marick. È ancora necessario eseguire test esplorativi e test di usabilità manualmente. Ma è quello che dovresti usare per i tuoi costosi e preziosi esseri umani - non i test di regressione. La chiave è che è necessario mettere in atto una pipeline di distribuzione in modo che si limitino a eseguire costose convalide manuali contro build che hanno superato una suite completa di test automatizzati. In questo modo riduci sia la quantità di denaro speso per i test manuali, sia il numero di bug che riescono a eseguire test o produzione manuali (tempo in cui sono molto costosi da correggere). Le prove automatizzate fatte correttamente sono molto più economiche durante il ciclo di vita del prodotto, ma ovviamente è una spesa in conto capitale che si ammortizza nel tempo.

Database access is hard to test without bulky fixtures, and even that won't cover weird corner cases in your data storage. Likewise security and many other things. Only business-layer code is effectively unit-testable.

L'accesso al database è testato implicitamente dai test di accettazione funzionale basati su scenari end-to-end. La sicurezza richiederà una combinazione di test automatici e manuali - test di penetrazione automatizzati e analisi statiche per trovare (ad es.) Sovraccarichi del buffer.

Even in the business layer, most code out there is not simple functions whose arguments and return values can be easily isolated for test purposes. You can spend lots of time building mock objects, which might not correspond to the real implementations.

Naturalmente i test automatici sono costosi se si costruiscono male il software e i test. Consiglio vivamente di controllare il libro "software orientato agli oggetti in crescita, guidato dai test" per capire come farlo nel modo giusto affinché i test e il codice siano mantenibili nel tempo.

Integration/functional tests supplement unit tests, but these take a lot of time to run because they usually involve reinitializing the entire system on each test. (If you don't reinitialize, the test environment is inconsistent.)

Uno dei prodotti su cui ho lavorato ha una suite di 3.500 test di accettazione end-to-end che impiegano 18 ore per essere eseguito. Lo eseguiamo in parallelo su una griglia di 70 box e riceviamo feedback in 45m. Ancora più lungo dell'ideale, ed è per questo che lo gestiamo come la seconda fase della pipeline dopo che i test unitari sono stati eseguiti in pochi minuti, quindi non sprechiamo le risorse su una build che non abbiamo un livello base di fiducia in.

Refactoring or any other changes break lots of tests. You spend lots of time fixing them. If it's a matter of validating meaningful spec changes, that's fine, but often tests break because of meaningless low-level implementation details, not stuff that really provides important information. Often the tweaking is focused on reworking the internals of the test, not on truly checking the functionality that is being tested.

Se il tuo codice e i test sono ben incapsulati e accoppiati liberamente, il refactoring non interromperà molti test. Nel nostro libro descriviamo come fare la stessa cosa anche per i test funzionali. Se i test di accettazione si interrompono, è un segno che manchi uno o più test unitari, quindi parte del CD implica il miglioramento costante della copertura del test per cercare e trovare bug in precedenza nel processo di consegna in cui i test sono più a grana fine e i bug sono meno costosi da risolvere.

Field reports on bugs cannot easily be matched with the precise micro-version of the code.

Se stai testando e rilasciando più frequentemente (parte del punto del CD), allora è relativamente semplice per identificare la modifica che ha causato il bug. L'intero punto del CD è ottimizzare il ciclo di feedback in modo da poter identificare i bug il prima possibile dopo averli controllati per il controllo della versione - e in effetti, preferibilmente prima di essere registrati (motivo per cui eseguiamo i test di compilazione e unità prima del check-in).

    
risposta data 09.12.2011 - 20:28
fonte
11

In primo luogo, il CD prende un grande aggiustamento mentale - devi ammettere che a volte le cose andranno a rotoli, non importa quello che fai. Alla fine della giornata, non puoi provare un risultato negativo.

Una volta superato questo, ti rendi conto che hai bisogno di strumenti e procedure per a) rilevare questi errori molto rapidamente eb) o ripristinare o distribuire l'aggiornamento in modo molto efficiente. Inoltre, se si sta veramente bevendo il cocktail del CD, si stanno realizzando molti piccoli cambiamenti puntati che sono facili da eseguire e non dovrebbero essere in grado di introdurre i principali bug a livello di applicazione. Persino i ragazzi che praticano veramente i CD gestiscono i cambi più importanti in un modo più tradizionale.

    
risposta data 09.12.2011 - 14:10
fonte
2

Ogni sistema ha dei rischi e ogni rischio ha dei costi potenziali. Se il costo di un piccolo rischio, del tipo che potrebbe richiedere mesi o anni per trovare test approfonditi e QA, è abbastanza alto (il software nel pacemaker cardiaco), non si effettuano spedizioni senza un lungo periodo di test di un rilascio congelato. Se il costo del fallimento è abbastanza piccolo, forse spedisci continuamente con test zero (la pagina Facebook del tuo gatto).

    
risposta data 11.12.2011 - 18:40
fonte
1

Full test coverage is impossible. You have to put in lots of time -- and time is money -- for every little thing. This is valuable, but the time could be spent contributing to quality in other ways.

Non hai bisogno di copertura al 100%, hai bisogno di abbastanza per essere sicuro del tuo sistema, che le modifiche a un posto non infrangeranno le cose che hai provato in precedenza.

Some things are hard to test automatically. E.g. GUI. Even Selenium won't
tell you if your GUI is wonky. Database access is hard to test without bulky fixtures, and even that won't cover weird corner cases in your data storage.

L'accesso al database è banale per scrivere comunque. Non dovresti aver bisogno di molti test sul tuo livello dati poiché sta solo recuperando e impostando i dati. La cosa più importante è garantire che quando fallisce, esegue il rollback e registra il problema in modo da poterlo risolvere.

Likewise security and many other things. Only business-layer code is effectively unit-testable. Even in the business layer, most code out there is not simple functions whose arguments and return values can be easily isolated for test purposes.

Quindi molte delle tue funzioni / classi sono troppo grandi. Dovrebbero essere scritti per essere testabili.

You can spend lots of time building mock objects, which might not correspond to the real implementations.

L'I / O dell'oggetto fittizio dovrebbe corrispondere a quanto previsto tuttavia. Cosa succede al suo interno senza importanza.

Integration/functional tests supplement unit tests, but these take a lot of time to run because they usually involve reinitializing the entire system on each test. (If you don't reinitialize, the test environment is inconsistent.)

Questi non dovrebbero essere eseguiti tutto il tempo. Proprio come necessario.

Refactoring or any other changes break lots of tests. You spend lots of time fixing them. If it's a matter of validating meaningful spec changes, that's fine, but often tests break because of meaningless low-level implementation details, not stuff that really provides important information. Often the tweaking is focused on reworking the internals of the test, not on truly checking the functionality that is being tested.

Quindi il tuo codice è troppo stretto e i tuoi test sono scritti male.

Field reports on bugs cannot easily be matched with the precise micro-version of the code.

Non sei sicuro di cosa stai ricevendo qui? Se c'è un bug, scrivi un test per dimostrarne l'esistenza, quindi risolvilo.

    
risposta data 09.12.2011 - 15:50
fonte
1

Funziona bene per noi, ma i nostri clienti sono per lo più interni. Molteplici build fatte durante il giorno, le build rotte non sono tollerate, il meccanismo di avvio web viene utilizzato in modo che gli utenti ottengano l'ultima versione ogni lancio. Una cosa è che il CD fa andare via molti problemi. Sì, hai sempre problemi di compatibilità, tuttavia, dal momento che stai distribuendo piccole modifiche ogni volta, le preoccupazioni sono davvero facili da gestire. Il livello di stress del CD è MOLTO più basso rispetto a quando facevamo grandi aggiornamenti e dovevamo sperare che tutto fosse perfetto dato che ci sarebbe stato così tanto codice da rivedere in caso di rottura.

    
risposta data 09.12.2011 - 15:58
fonte
-4

Per essere onesti, TUTTO il software è in consegna continua! La cosa più importante è tirarla fuori dalla porta! Fai in modo che i tuoi utenti lo usino e assegni la priorità alle richieste di funzionalità e al bug-squashing.

"Nave di veri artisti"
- Steve Jobs.

    
risposta data 10.12.2011 - 18:35
fonte

Leggi altre domande sui tag