Anche quando si parla di "Infrastructure as Code" (infrastruttura come codice) è possibile classificare ciascuna delle attività di test come immediata o eventuale.
Il test immediato viene eseguito quando si invia il codice. I test eventuali avvengono dopo un certo ritardo, forse dopo una revisione manuale, o forse in base a un programma. Idealmente, il test è veramente immediato, avviene durante la scrittura del codice. Esistono attività di convalida che vengono eseguite nell'editor, come l'evidenziazione della sintassi o l'esecuzione di unit test. Il Language Server Protocol (LSP) definisce uno standard per l'integrazione del controllo della sintassi negli IDE, supportato da implementazioni per vari linguaggi. Le persone che preferiscono la riga di comando come ambiente di sviluppo possono utilizzare un'utilità come inotifywait o entr per eseguire controlli in un terminale quando il codice cambia. Un altro esempio di convalida immediata è la programmazione in (Pair programming), che è essenzialmente una revisione del codice che avviene mentre lavori. Il lavorare in coppia fornisce un feedback molto più rapido rispetto alle revisioni del codice che avvengono dopo che hai finito di lavorare su una storia o una funzione e qualcun altro trova il tempo per rivedere ciò che hai fatto. La build CI e la pipeline CD dovrebbero essere eseguite immediatamente ogni volta che qualcuno inserisce una modifica al codebase. L'esecuzione immediata di ogni modifica non solo fornisce un feedback più rapido, ma garantisce anche un piccolo ambito di modifica per ogni esecuzione. Se la pipeline viene eseguita solo periodicamente, potrebbe includere più modifiche da più persone. Se uno qualsiasi dei test fallisce, è più difficile capire quale cambiamento ha causato il problema, il che significa che più persone devono essere coinvolte e dedicare tempo a trovarlo e risolverlo.
Cosa dovremmo testare con l'infrastruttura?
L'essenza di CI è testare ogni cambiamento che qualcuno apporta il prima possibile. L'essenza del CD è massimizzare la portata di quel test. Come afferma Jez Humble, "Otteniamo tutto questo assicurandoci che il nostro codice sia sempre in uno stato distribuibile". La garanzia della qualità riguarda la gestione dei rischi derivanti dall'applicazione del codice al sistema. Il codice si interromperà quando applicato? Crea la giusta infrastruttura? L'infrastruttura funziona come dovrebbe? Soddisfa i criteri operativi per prestazioni, affidabilità e sicurezza? Rispetta le regole normative e di governance? CD riguarda l'ampliamento della portata dei rischi che vengono immediatamente testati quando si invia una modifica al codebase, piuttosto che attendere eventuali giorni di test, settimane o addirittura mesi dopo. Quindi, a ogni push, una pipeline applica il codice ad ambienti di test realistici ed esegue test completi. Idealmente, una volta che il codice ha eseguito le fasi automatizzate della pipeline, è completamente dimostrato di essere pronto per la produzione. I team dovrebbero identificare i rischi che derivano dall'apportare modifiche al codice dell'infrastruttura e creare un processo ripetibile per testare una determinata modifica rispetto a tali rischi. Questo processo assume la forma di suite di test automatizzate e test manuali. Una suite di test è una raccolta di test automatizzati che vengono eseguiti come gruppo. Quando le persone pensano ai test automatizzati, generalmente pensano a test funzionali come i test unitari e i test di applicativi basati sull'interfaccia utente. Ma la portata dei rischi è più ampia dei difetti funzionali, quindi anche la portata della convalida è più ampia. I vincoli e i requisiti oltre a quelli puramente funzionali sono spesso chiamati requisiti non funzionali (NFR) o requisiti interfunzionali (CFR).
Esempi di cose che potresti voler convalidare, automaticamente o manualmente, includono:
Qualità del codice
Il codice è leggibile e gestibile? Segue gli standard del team su come formattare e strutturare il codice? A seconda degli strumenti e delle lingue che stai utilizzando, alcuni strumenti possono eseguire la scansione del codice per errori di sintassi e conformità alle regole di formattazione ed eseguire un'analisi della complessità. A seconda del tempo che sono in circolazione e di quanto sono popolari, i linguaggi dell'infrastruttura potrebbero non avere molti (o nessuno!) di questi strumenti. I metodi di revisione manuale includono processi di revisione del codice gated, sessioni di presentazione del codice e programmazione in coppia (Pair programming).
Funzionalità
Fa quello che dovrebbe? Infine, la funzionalità viene testata distribuendo le applicazioni sull'infrastruttura e verificando che vengano eseguite correttamente. In questo modo indirettamente viene verificata la correttezza dell'infrastruttura, ma spesso è possibile rilevare i problemi prima di distribuire le applicazioni. Un esempio di ciò per l'infrastruttura è il routing di rete. È possibile stabilire una connessione HTTPS dall'Internet pubblica ai server Web? Potresti essere in grado di testare questo tipo di cose utilizzando un sottoinsieme dell'intera infrastruttura.
Sicurezza
È possibile testare la sicurezza a più livelli, dalla scansione del codice allo unit test, al test di integrazione e al monitoraggio della produzione. Esistono alcuni strumenti specifici per i test di sicurezza, come gli scanner di vulnerabilità. Può anche essere utile scrivere test di sicurezza in suite di test standard. Ad esempio, gli unit test possono fare controlli sulle porte aperte, sulla gestione degli account utente o sulle autorizzazioni di accesso. I sistemi di conformità potrebbero dover rispettare leggi, regolamenti, standard di settore, obblighi contrattuali o politiche organizzative. Garantire e dimostrare la conformità può richiedere molto tempo per i team dell'infrastruttura e delle operazioni. I test automatizzati possono essere enormemente utili con questo, sia per rilevare rapidamente le violazioni sia per fornire prove ai revisori. Come per la sicurezza, puoi farlo a più livelli di convalida, dal livello di codice al test di produzione. Vedere "Governance in un flusso di lavoro basato su pipeline" per uno sguardo più ampio su come farlo.
Prestazione
Gli strumenti automatizzati possono testare la velocità con cui vengono completate azioni specifiche. Testare la velocità di una connessione di rete dal punto A al punto B può far emergere problemi con la configurazione di rete o la piattaforma cloud se eseguita prima ancora di distribuire un'applicazione. La ricerca di problemi di prestazioni in un sottoinsieme del sistema è un altro esempio di come ottenere un feedback più rapido.
Scalabilità
I test automatizzati possono dimostrare che il ridimensionamento funziona correttamente; ad esempio, controllando che un cluster a scalabilità automatica aggiunga nodi quando dovrebbe. I test possono anche verificare se il ridimensionamento offre i risultati attesi. Ad esempio, forse l'aggiunta di nodi al cluster non migliora la capacità, a causa di un collo di bottiglia da qualche altra parte nel sistema. L'esecuzione frequente di questi test significa che scoprirai rapidamente se una modifica alla tua infrastruttura interrompe la scalabilità.
Disponibilità
Allo stesso modo, i test automatici possono dimostrare che il sistema sarebbe disponibile in caso di potenziali interruzioni. I tuoi test possono distruggere le risorse, come i nodi di un cluster, e verificare che il cluster le sostituisca automaticamente. Puoi anche verificare che gli scenari che non vengono risolti automaticamente vengano gestiti correttamente; ad esempio, mostrare una pagina di errore ed evitare il danneggiamento dei dati.
Operabilità
È possibile testare automaticamente qualsiasi altro requisito di sistema necessario per le operazioni. I team possono testare il monitoraggio (inserire errori e dimostrare che il monitoraggio li rileva e li segnala), la registrazione e le attività di manutenzione automatizzata.
