Come abilitare il mio team a eseguire test di integrazione con RedShift in parallelo?

Question

Come abilitare il mio team a eseguire test di integrazione con RedShift in parallelo?

#1 da (3 voti)
#2 da (1 voti)

4

Sto lavorando con Docker per eseguire i miei test di integrazione, funziona molto bene:

avvio i miei contenitori docker (uno con il mio server e uno con il database)
Eseguo l'IT utilizzando arquillian contro questi contenitori

Ora ci stiamo spostando su AWS e vorremmo utilizzare Amazon RedShift per alcune analisi. Il problema è che RedShift è disponibile solo in AWS, quindi non posso creare un'immagine RedShift per Docker.

Mi piacerebbe avere un modo in cui molti sviluppatori + server CI possono eseguire test in parallelo (senza influenzare i reciproci risultati).

Ho cercato qualsiasi riferimento su come le persone lo fanno, ma non ho trovato nulla tranne per questo post di Serenytics , che non è esattamente quello di cui ho bisogno.

Le possibilità che vedo sono:

Utilizza uno schema per ogni sviluppatore / server CI
Usa un'immagine Docker di Postgres per gli sviluppatori e un vero RedShift per il Server CI.

Informazioni sul numero 1: verrebbe eseguito contro il DB reale in tutte le istanze, ma avremmo bisogno di avere una configurazione "privata" per ogni sviluppatore e avremmo più schemi nel database solo per il test.

Numero 2: non corriamo contro il motore DB reale, quindi forse non tutto sarebbe supportato da Postgres. Potrebbe causare problemi nel prossimo futuro.

Immagino di non essere il primo con questo problema. Come posso configurare i miei test così tante persone possono eseguire i test in parallelo e non inquina il mio database?

testing integration-tests

posta JSBach 22.02.2016 - 09:48

fonte

2 risposte

1

In pratica ci sono alcune piccole differenze tra Redshift e un Postgres recente, come ad esempio:

ordine di righe nel set di query
conversione del fuso orario
data diff function

quindi preferisco eseguire i test direttamente su Redshift.

Credo che la soluzione migliore per impostare i test in modo che molte persone possano eseguirli in parallelo è usare nomi casuali per i tuoi database / tabelle (ad esempio test_ + uuid o timestamp, quindi non c'è collisione tra i test runner). Quindi è necessario assicurarsi che tutti questi database / tabelle temporanee vengano correttamente eliminati alla fine dei test.

risposta data 23.02.2016 - 09:45

fonte

Leggi altre domande sui tag testing integration-tests

Framework plugin per software estensibile Composizione e chiamata dei metodi di parte

score 3 · Accepted Answer

Non ho mai lavorato con RedShift da solo, ma la situazione che descrivi non è così speciale per questa tecnologia specifica.

L'uso di due diverse tecnologie di database può essere complicato, tuttavia, quando si ha la possibilità di mantenere l'architettura del proprio sistema aperta a diverse tecnologie di back-end con un minimo sforzo, raccomanderei di utilizzare tale possibilità. Quindi se i tuoi sviluppatori si preoccupano di rendere le applicazioni compatibili con PostgreSQL e RedShift (che è, secondo Wikipedia , basato anche su PostgreSQL 8.0.2), si ottiene una flessibilità che non è solo utile per test più semplici. Ciò renderà inoltre più semplice passare a una nuova versione di back-end in futuro o supportare i fornitori di host aggiuntivi se ciò sarà necessario in futuro.

Quindi perché non interpretare l'opzione n. 2 come un vantaggio, per avere la possibilità di eseguire test su due (leggermente) diversi sistemi di backend? Ovviamente, dovrai "astrarre" le differenze tra i sistemi e informare i tuoi sviluppatori quali restrizioni SQL devono obbedire. Amazon fornisce un elenco qui , e ci sono ulteriori dettagli ( come quelli menzionati da @AdrienChauve) il tuo team deve imparare, ma mi aspetto che sia una fase di apprendimento iniziale, non una cosa che rallenta costantemente la tua squadra.

Naturalmente, potrebbero esserci alcuni test non riusciti sul backend "reale" RedShift che sono stati trascurati usando il backend PostgreSQL - questo è ciò che i test servono, giusto? Di cosa ti devi preoccupare se scegli questa strada: assicurati di non sviluppare solo su un server PostgreSQL per diverse settimane e passa successivamente a Redshift, ma di testare su Redshift regolarmente e immediatamente quando i test su PostgreSQL sono fatti. Dal momento che hai menzionato un server CI, immagino sia quello che avevi già in mente.

Inoltre, consiglierei anche di lasciare la porta aperta per l'opzione # 1. Un nome di schema fisso non dovrebbe essere codificato nelle tue applicazioni, e più schemi in un database per il test possono andare bene, purché non sia necessario riempire ogni schema di test con un'enorme quantità di dati di test. E se ti imbatti davvero nella situazione in cui devi eseguire test in parallelo direttamente su RedShift, ma per schemi diversi, puoi comunque decidere di farlo.