Come evitare le continue instabilità causate dall'integrazione negli ambienti di test?

Supponiamo che tu stia utilizzando processi di integrazione continua che aggiornano frequentemente alcuni ambienti di destinazione, in modo che ogni volta che ci siano delle modifiche "tu" puoi testare immediatamente le tue modifiche. Fa parte degli obiettivi di CI, no?

Ma supponi anche di avere altre persone coinvolte nel tuo ciclo di test, ad esempio manager o clienti. Ha senso coinvolgere altre persone nel tentativo di rivedere (rompere?) Le tue prossime modifiche, no?

Ma se continui continuamente a fornire cambiamenti nell'ambiente in cui quelle altre persone, seriamente, stanno provando a testarli, potrebbero sorgere più problemi, come:

• they potrebbe perdere tempo a segnalare problemi che, quando salvano il rapporto (approfondito), non sono più in grado di riprodurre il problema da soli (ad esempio perché accidentalmente hai riscontrato lo stesso problema e lo hai già risolto nel loro ambiente).
• you potrebbe non essere in grado di riprodurre i problemi segnalati, poiché gli ambienti in cui si sono imbattuti in alcuni problemi, non sono più identici (tu (!!!) potresti aver sovrapposto il loro ambiente).

Quindi cosa puoi fare (come configurare le cose?) Per evitare situazioni così (frustranti)?

Darò la mia esperienza su questo, soprattutto perché mostra perché alcune risposte non sono sempre applicabili.

Alcuni contesti per iniziare:

• Abbiamo 7 ambienti per ospitare circa 80 applicazioni, la maggior parte delle quali si basa l'una sull'altra attraverso servizi Web o tabelle condivise su db2-iSeries.
• Nel bene o nel male, iSeries è il nostro sistema di riferimento DB.
• Quest'ultimo punto invalida l'idea di portare l'app con le sue dipendenze in un ambiente isolato in quanto la creazione di un AS400 per ciascuno costerebbe troppo e non avremmo l'hardware per eseguirlo comunque.

Quello che stiamo facendo non è una consegna continua automatizzata completa, abbiamo un programma di rilasci per far apparire una serie coerente di applicazioni per le operazioni generali. A parte ciò, ogni team di test può attivare una versione in uno degli ambienti di Q / A per l'applicazione che sta testando e può bloccare alcune versioni dell'applicazione per evitare che un'altra richiesta del team rompa i propri test.

Le dipendenze delle applicazioni vengono verificate prima del rilascio, quindi il sistema non rilascerà qualcosa se altre applicazioni non possono essere aggiornate o non corrispondono alle sue dipendenze necessarie. L'idea principale è consentire gli aggiornamenti quando non avrà alcun impatto su qualcuno, se non ci sono test pianificati, dovrebbe fluire dall'ambiente precedente (e stiamo puntando a rimuovere le versioni pianificate nei primi 5 ambienti a medio termine ora che abbiamo convalidato questo sistema di metodo "su richiesta").

La versione breve prevede un sistema a "semaforo" attorno alle applicazioni nell'ambiente, un team dovrebbe essere in grado di bloccare l'applicazione di destinazione con le sue dipendenze (e dipendenze transitive) per il tempo dei test manuali.
L'implementazione di questo semaforo dipende fortemente dal sistema di automazione, quindi non mi estenderò.

Naturalmente il modo più semplice è, come altri hanno già detto, creare un nuovo ambiente per un'applicazione con tutte le sue dipendenze per evitare il semaforo sopra descritto.

Sembra che tu stia parlando di un ambiente di test che viene costantemente riutilizzato senza essere reinizializzato in modo affidabile per ogni esecuzione del test. Questo rende tale test inaffidabile. Simile, dal punto di vista dell'affidabilità, con test manuali, se lo si desidera.

IMHO non dovresti usare tali test all'interno dei tuoi scopi di qualifica CI / CD poiché ciò invaliderà effettivamente il processo di qualificazione (almeno in quella zona). Dire che il software supera il test X senza eseguire effettivamente il test X per ogni versione del software fornita o senza avere la certezza che il passrisultato ottenuto non sia accidentale (a causa di falsi positivi) comprometterà il livello di confidenza del test. I falsi negativi non danneggiano la credibilità, ma sono anche indesiderati a causa del "rumore" non necessario che creano.

Va bene eseguire tali test al di fuori del processo di qualifica CI / CD. Ma tratteresti un risultato fallito in tali test proprio come un bug trovato dal cliente: dovresti riprodurre in modo affidabile il problema per essere in grado di sviluppare una correzione per esso e confermare che la correzione funziona. E non puoi davvero farlo se il test non è affidabile.

Se si prevede di risolvere il problema, idealmente si dovrebbe prima sviluppare un caso di test automatizzato e affidabile per riprodurre il problema. Che useresti per sviluppare una correzione e confermarne l'efficacia (il risultato del test dovrebbe passare da FAIL a PASS). È anche possibile (dovrebbe?) Collocare questo testcase all'interno del processo di qualifica CI / CD per evitare il ripetersi futuro, se lo si desidera - per aumentare il livello generale di qualità delle versioni del software.

L'approccio abituale è creare ambienti diversi:

DEV - questo è il luogo in cui il team di sviluppo rovina le cose. Qui puoi creare tutte le modifiche delle modifiche, distribuire la nuova versione e così via. Ecco il luogo in cui CI è completamente integrato.

PREPROD / QA - questo è il posto in cui "gioca" il team QA / test / validation fa i test. Questo ambiente di solito si blocca durante i test. L'integrazione di CI con questo ambiente è solo per fornire una nuova versione del prodotto, configurazioni, ecc.

PRODUZIONE - è necessario spiegare :)?

Se stai eseguendo CI / CD, ciò implica che ci sono alcuni test automatici in corso (CI) prima della distribuzione (CD). Se riscontri molti problemi nel tuo ambiente di test, ciò significa che non vengono colti dai test eseguiti prima della distribuzione; questo indica un test automatico insufficiente. Se gli sviluppatori riscontrano problemi in cui i difetti vengono rilevati negli ambienti di test, è necessario migliorare le loro suite di test automatizzate per evitare ciò. Ciò migliorerà anche la qualità e l'affidabilità in generale, fino alla produzione.

Per aggiungere alla risposta di Romeo Ninov, internamente in un ambiente è necessario provare a separare il più possibile le applicazioni. Questo è in parte il motivo per cui la finestra mobile ha avuto così tanto successo per dev / test. Ti fa quasi finta di non condividere affatto un ambiente.

L'altra opzione è quella di avere server ben definiti su cui girano le applicazioni che sono separate dal resto dell'infrastruttura che costituisce il tuo ambiente. Vale a dire. Tutti i macchinari per la gestione o l'abilitazione dell'ambiente vanno su server separati e di lunga durata. Quindi collegare nuovi server di breve durata basati su un'immagine nota per testare un'applicazione e, se vengono apportate modifiche all'immagine di base, è necessario applicare tali modifiche ovunque per ogni nuovo componente. Il che significa testare le modifiche su tutto.

Se un team di appdev chiede una modifica che interrompe l'applicazione di qualcun altro, quindi sfortuna, deve creare internamente un mitigante nel proprio codice e mantenere i propri requisiti specifici separati dall'offerta degli ambienti.