Come eseguire un test di verifica lungo (10 ore di funzionamento) per l'integrazione continua di software scientifico

Credo che tu abbia tre problemi qui.

1. Esecuzione di test asincroni
2. Credenziali di sicurezza
3. Gateway di qualità

Test asincroni

Sebbene non sia l'ideale, Jenkins è stato progettato per carichi di lavoro sincroni. C'è sicuramente una discrepanza qui.

Quindi la mia prima domanda è: come fai a sapere quando i test sono stati completati, nel bene o nel male?

• Se devi eseguire il polling di una directory o di un servizio per lo stato e i risultati, avvia semplicemente tale polling come passaggio successivo alla presentazione del lavoro.
• Se ricevi un evento, dividi la pipeline in due segmenti. Avere il secondo segmento attivato ricevendo quell'evento. Potrebbe essere necessario scrivere un piccolo programma per mappare l'evento inviato dal tuo cluster in una richiesta web per attivare la fase successiva in jenkins.

Credenziali di sicurezza

Jenkins è in grado di memorizzare le informazioni chiave in modo sicuro utilizzando la sua gestione delle credenziali interne. Ciò richiederà la creazione di una chiave specifica per Jenkins. Questo potrebbe avere un lato positivo nel permettere che i dati di utilizzo vengano raccolti, e forse anche le limitazioni da imporre sull'account specifico di Jenkins sul cluster di calcolo.

Gateway di qualità

Le pipeline di integrazione continua sono strutturate in modo da fornire feed-back il più rapidamente possibile.

Quindi quando dici che il test dura dieci ore, mi rendo conto che sto ascoltando dieci ore prima che i eventuali risultati siano disponibili. Ora ci vogliono dieci ore per completare i test, anzi ci sono progetti che richiedono giorni per testare completamente. Il punto è che Continuous significa un flusso di informazioni, deve essere disponibile in modo tempestivo non dieci ore più tardi.

Pensa al gasdotto come al sollevamento di un misuratore di qualità. Ogni fase del gasdotto spinge quel metro più in alto. Vuoi programmare le tue fasi in modo tale da scoprire gli errori in anticipo, essenzialmente spingendo il misuratore della qualità il più rapidamente possibile.

Ciò massimizza la probabilità che lo sviluppatore stia ancora pensando a quel problema e possa risolverlo rapidamente. Inoltre, massimizza il risparmio totale di risorse possibile, scoprendo che la build è prima sbagliata e non sta perseguendo ulteriori verifiche. Anche la richiesta di pull può essere rifiutata prima, poiché ogni errore è un fermo di scena.

Test Suites

Quindi prova a suddividere i tuoi test in suite di test a breve durata. Ovunque tra 15 minuti e 1 ora sono buone lunghezze. Molto più breve e il sovraccarico diventa gravoso, molto più lungo ei risultati non mantengono quella continuità del flusso di informazioni. Prova e pianifica prima i test più brevi (per quel rapido turnaround), ma compensa il tempo totale per il completamento. Potrebbe essere logico operare una singola coda di test più veloci e parallelizzare i test più lunghi a fianco.

Test dei fumi

I test del fumo sono un'altra via per ridurre il tempo di scoperta di un errore, riducendo la dimensione del problema e eseguendo una singola variante di un algoritmo in primo piano. Il test sarà eseguito più velocemente dei suoi cugini più pesanti e eserciterà anche gran parte della meccanica. Non è completo come i test più pesanti, ma individuerà problemi evidenti prima. Di nuovo bilanciate queste cose perché non sostituiscono i vostri test attuali, servono a delineare sezioni importanti nella speranza di identificare le rotture prima.

Riduci la dipendenza dalla piattaforma

Mentre è ancora necessario il passaggio di verifica finale sul cluster di calcolo, la maggior parte degli errori è rilevabile come test di unità. Maggiore è l'algoritmo che puoi coprire nei test di unità, più velocemente puoi dimostrare di non essere stato infranto. Come test di unità bonus non è necessario il cluster di calcolo per essere eseguito.

È bello che tu stia cercando di implementare una sorta di integrazione continua, ma qui non sembra una buona idea. Non è possibile eseguire la suite di test completa prima di unire le modifiche, almeno non senza compromettere notevolmente la produttività. È quindi necessario valutare se i benefici di questi test lenti superano i loro costi (qui, probabilmente costi letterali per il tempo nel cluster).

Quindi puoi escogitare una strategia per ridurre i costi. Ad esempio:

• eseguire la suite di test completa con minore frequenza, ad es. ogni sera o prima di un rilascio.
• usa una suite di test più piccola per CI. L'obiettivo di questa suite di test non è dimostrare che funzioni, ma solo rilevare problemi evidenti in anticipo (una sorta di test del fumo ).

Ci sono molte possibilità per creare una suite di test più piccola e più veloce:

• Se la suite di test è costituita da più problemi, seleziona solo un sottoinsieme per i test CI, possibilmente a caso.
• Scegli le dimensioni dei problemi più piccole. Per esempio. ridurre la risoluzione o la durata delle simulazioni. Utilizza set di dati campionati.
• Concentrati sui test dei componenti piuttosto che sulle esecuzioni complete del software.

Per essere chiari: è del tutto normale non eseguire test CI. Non sarebbe grandioso, ma può essere una decisione valida se sei consapevole dei rischi. (Principalmente, il rischio che il software fosse rotto senza che nessuno se ne accorgesse). Ma se l'unico modo per fare un commit è aspettare ore o addirittura giorni, potrebbe essere peggio di nessun test. Finché continui a eseguire regolarmente la suite di test completa, puoi evitare il rischio che le cose si interrompano senza preavviso. Mentre non sarai avvisato prima che il difetto è fuso, sarai comunque avvisato vicino alla causa del problema.

Le tue difficoltà tecniche nella configurazione di Jenkins sono minori a questo riguardo. Probabilmente il tuo meccanismo di invio del lavoro HPC implica che mentre Jenkins è adatto a dare il via ai lavori HPC, Jenkins potrebbe non essere una piattaforma adatta per aggregare i risultati dei test o le fusioni dei branch gating. Questo potrebbe non essere un problema enorme, ad es. se rinunci all'obiettivo di unioni gated in stile CI, accetti invece i test notturni. Quindi, potrebbe essere sufficiente che gli sviluppatori trovino i risultati come e-mail la mattina successiva.

L'integrazione continua con test eseguiti per ore / giorni non è un'integrazione continua.

Seriamente ci hai appena riportato ai tempi delle build notturne. Ora non c'è alcun motivo LOGICO che un test debba essere completato in modo tempestivo. Ma gli umani perdono i benefici dell'integrazione continua se lo fai.

L'integrazione continua garantisce che l'integrazione sia eseguita dalla stessa persona che ha apportato queste modifiche. Costringe i programmatori a vedere come la loro roba influisce su altre cose prima che rompano quella roba.

Se posso trasformare la roba e andare in vacanza e perdere completamente la caduta causata dalle mie cose, smettila di chiamarla integrazione continua. Non mi interessa quali strumenti hai usato.