Dove eseguo i miei test di integrazione

Naviga le tue risposte
6

Al momento disponiamo di 4 ambienti per un progetto (local / dev, test, accettazione, produzione). Abbiamo creato alcuni test di integrazione che vogliono essere eseguiti. La grande domanda che ora abbiamo è dove eseguirli?

  1. Eseguili su tutti gli ambienti. Il pro di questo è che sappiamo per certo che funziona su tutti gli ambienti. Gli svantaggi sono che a) non si desidera sottolineare il proprio ambiente di produzione con i test, b) Non tutti i test possono essere preformati in produzione a partire dai riferimenti esterni di terze parti anche di produzione

  2. Eseguili su un singolo ambiente. Quindi scegli uno dei quattro. Il problema con questo è che le impostazioni specifiche dell'ambiente (database, config) possono causare bug. Quindi se esegui test corretti sul bug dell'ambiente di test a causa di un bug di configurazione in produzione si rompe.

  3. Crea un ambiente di produzione al volo sovrascrivi solo le impostazioni di cui hai realmente bisogno per il test ed esegui i tuoi test su quelle. I pro di questo approccio sono che per la produzione si filtrano il più possibile i bug di impostazioni specifiche dell'ambiente. Possono ancora verificarsi nell'altro ambiente, ma le conseguenze sono minori. Gli aspetti negativi sono che questo approccio richiede un po 'di tempo per essere configurato, può essere saltato minimizzando le differenze tra gli ambienti.

Mi chiedo, c'è uno standard per questo? Cosa sarebbe normalmente fatto?

    
posta Maarten Kieft 15.09.2016 - 14:38
fonte

1 risposta

6

Li avresti eseguiti nell'ambiente di test / accettazione. L'ambiente di accettazione dovrebbe imitare la produzione (il più possibile). Le uniche differenze dovrebbero essere la configurazione e possibilmente la quantità di server (questo dipende da come viene distribuito). Io uso strumenti automatici che convalidano la configurazione (e fallisce la distribuzione prima che inizi o durante la stessa), forse potresti usare un approccio simile. Il mio strumento di distribuzione (Octopus Deploy) può gestire i rollback.

Sidenote 1: non dovresti mai scrivere test contro la produzione né clonare il tuo ambiente di produzione. Potresti provare a utilizzare un metodo Blue Green Deployment e questo significherebbe che sarai in grado di percepire il controllo che viene distribuito nel tuo inattivo ambiente di produzione prima di cambiare il / i carico / i di bilanciamento del carico. Possibilmente anche eseguire alcuni strumenti di convalida per tutto ciò che è stato distribuito.

Sidenote 2: Non so perché abbiate sia ambienti di test che di accettazione, a meno che non si tratti di una sorta di esigenza aziendale, ma eseguirò test di integrazione su entrambi. Abbiamo, sviluppo, qualità (accettazione) e produzione. I nostri test di integrazione (connettività di database, ecc.) Funzionano su tutto ma non sulla produzione. I nostri test di accettazione si basano sulla qualità (accettazione). È possibile eseguire i test di integrazione localmente se si dispone di tutti i sistemi necessari installati localmente, ad esempio se ci si connette a SQL, Mongo, Redis ma per noi ciò non è possibile.

    
risposta data 15.09.2016 - 14:50
fonte

Leggi altre domande sui tag

Struttura del database per salvare le 'tabelle' Come implementare lo schema della macchina dello stato sulla radice aggregata