Si parla tanto di DevOps e alle conferenze gli argomenti più gettonati sono build pipeline, continuous integration/delivery/deploy, deploy automation e monitoring.
Ci stiamo dimenticando qualcosa... i test! dove sono i test? perché non si parla quasi mai di test? in questo fantastico mondo DevOps come si inseriscono i test?
I test sono solo un passo della pipeline di build? se la pensassi così il titolo del mio intervento sarebbe stato "Continuous Testing in DevOps", non credete?
5. THE SECONDTHE SECOND
WAYWAY
THE PRINCIPLES OFTHE PRINCIPLES OF
FEEDBACKFEEDBACK
The DevOps Handbook - Gene Kim, Jez Humble, Patrick
Debois, & John Willis
Total Testing in DevOps
5
7. Unit Test written by the programmers to convince
themselves that their programs work the way they think
the programs work.
Functional Test written by (or at least specified by) the
customers to convince themselves that the system as a
whole works the way they think the system as a whole
should work.
eXtreme Programming explained 1st ed - Kent Beck - p. 47
Total Testing in DevOps
7
11. AUTOMATED BUILD
FUNCTIONAL TESTFUNCTIONAL TEST
GOALGOAL
parte in automatico quando necessario
avvisa quando una build o i test falliscono
crea uno o più pacchetti software quando termina con
successo
Total Testing in DevOps
11 . 1
12. AUTOMATED BUILD
FUNCTIONAL TESTFUNCTIONAL TEST
TEST - FEEDBACKTEST - FEEDBACK
verifica manuale: trigger che avviano la build
verifica manuale: avvisi in caso di fallimento
verifica automatica: dei pacchetti creati
deploy dei pacchetti in ambiente di dev / test
esecuzione dei pacchetti in ambiente di dev / test
smoke / sanity test
Total Testing in DevOps
11 . 2
13. AUTOMATED BUILD
OTHER FEEDBACKOTHER FEEDBACK
usability: è facile e intuitivo usare il sistema di build?
lo stato delle build è chiaro? è facile identificare dove e
perché la build è fallita?
performance: la build è abbastanza rapida? possiamo
velocizzarla senza perdere affidabilità?
load il nostro sistema ci permette di effettuare più build
in contemporanea senza un significativo degrado delle
prestazioni?
Total Testing in DevOps
11 . 3
14. AUTOMATED BUILD
UNIT TESTUNIT TEST
La maggior parte degli strumenti di build ci
permettono di definire la build tramite un proprio DSL
oppure "scriverla" usando un linguaggio di
programmazione
BUILD AS CODE / PIPELINE AS CODEBUILD AS CODE / PIPELINE AS CODE
Total Testing in DevOps
11 . 4
15. DELIVERY
FUNCTIONAL TESTFUNCTIONAL TEST
lo schema di versionamento dei pacchetti è semplice ed
efficiente?
è facile distinguere i pacchetti validi da quelli non
installabili?
i pacchetti hanno un checksum per verificare che non
siano corrotti?
l'accesso all'artifactory rispetta i requisiti di sicurezza?
Total Testing in DevOps
12
16. CONF. MGMT & DEPLOY AUTOM.
FUNCTIONAL TESTFUNCTIONAL TEST
GOALGOAL
il deploy può essere lanciato premendo un pulsante
avvisa quando il deploy fallisce
permette i rollback delle configurazioni
permette i rollback delle versioni delle applicazioni
Total Testing in DevOps
13 . 1
17. CONF. MGMT & DEPLOY AUTOM.
FUNCTIONAL TESTFUNCTIONAL TEST
TEST - FEEDBACKTEST - FEEDBACK
verifica manuale: eventuali trigger che avviano il deploy
verifica manuale: avvisi in caso di fallimento
verifica (almeno manuale): rollback delle configurazioni
verifica (almeno manuale): rollback delle versioni
Total Testing in DevOps
13 . 2
18. CONF. MGMT & DEPLOY AUTOM.
OTHER FEEDBACK - PT.1OTHER FEEDBACK - PT.1
usability: le configurazioni sono facilmente
modificabili? è facile creare nuove configurazioni?
usability: è facile e intuitivo usare il sistema di deploy?
lo stato delle deploy è chiaro? è facile identificare dove
e perché il deploy è fallito?
Total Testing in DevOps
13 . 3
19. CONF. MGMT & DEPLOY AUTOM.
OTHER FEEDBACK - PT.2OTHER FEEDBACK - PT.2
performance: il deploy è abbastanza rapido?
possiamo velocizzarla senzo perdere affidabilità?
security: tutti i valori di configurazione sono presenti in
un VCS?
security: le configurazioni specifiche per i differenti
environment sono isolate tra loro? è possibile
configurare differenti livelli di accesso agli
environment?
Total Testing in DevOps
13 . 4
20. CONF. MGMT & DEPLOY AUTOM.
UNIT TESTUNIT TEST
La maggior parte degli strumenti di automazione dei
deploy e gestione delle configurazioni ci permettono
di definire il processo di deploy tramite un proprio
DSL ed esistono strumenti di test che verificano lo
stato di un server / container e.g. testinfra
DEPLOY AUTOMATION AS CODEDEPLOY AUTOMATION AS CODE
Total Testing in DevOps
13 . 5
21. OPERATE
Questa parte è specifica per ogni applicazione...
Operations significa amministrare e gestire il
funzionamento dell'applicazione e spesso necessita la
conoscienza del dominio applicativo
QUESTO NON SIGNIFICA CHE NON POSSAQUESTO NON SIGNIFICA CHE NON POSSA
ESSERE TESTATO E MIGLIORATO!ESSERE TESTATO E MIGLIORATO!
Total Testing in DevOps
14
22. MONITOR
Esso è un sistema molto potente per fornirci feedback e
informazioni relative alla nostra applicazione e su come
viene utilizzata.
Dovrebbe inviarci poche informazioni, ma esse devono
essere cariche di significato... se il sistema di monitoring
c'inviasse tutti i dati che raccogliesse sarebbe
praticamente inutile perché non sapremmo cosa farcene
di tutti quei dati.
Total Testing in DevOps
15 . 1
23. MONITOR
E' un argomento vasto e complesso e purtroppo non
abbiamo tempo per addentrarci nei dettagli.
Che informazioni può fornirci:
se una parte di codice rallenta la sua esecuzione
se una parte di codice genera più errori del normale
variazioni insolite del carico (sia positive che negative)
variazioni insolite nelle risorse utilizzate
Total Testing in DevOps
15 . 2
24. MONITOR
L'UTENTE È IL MIGLIOR "MONITOR" DELL'UTENTE È IL MIGLIOR "MONITOR" DEL
NOSTRO SISTEMA...NOSTRO SISTEMA...
Total Testing in DevOps
15 . 3
26. PLAN
La nostra applicazione ha una UI?
possiamo studiare la UX e testarla, prima di procedere
al design
Total Testing in DevOps
16 . 2
27. PLAN
Vogliamo lanciare una nuova funzionalità?
Possiamo testare l'idea tramite:
sondaggi rivolti agli utenti
landing page che mostrano la nuova funzionalità
Total Testing in DevOps
16 . 3
28. RIASSUMENDO
lo scopo non è automatizzare
lo scopo è ottenere feedback più rapidamente possibile
e prima che i problemi (bug / difetti) vadano in
produzione
possiamo testare l'applicazione e i processi che ci
permettono di metterla in produzione
Total Testing in DevOps
17 . 1
29. RIASSUMENDO
noi siamo gli utilizzatori dei tool, non il contrario!
noi siamo i "customer" del "ciclo infinito", quindi
definiamo i test funzionali e gli "acceptance test" del
nostro flusso di lavoro e dei tool che usiamo
tutto ciò che è codice (o considerabile tale), proviamo a
trattarlo come se lo fosse per davvero ... unit test, TDD,
branching model, etc.
Total Testing in DevOps
17 . 2