Memorizzazione di dati binari di grandi dimensioni per i test di integrazione

Question

Memorizzazione di dati binari di grandi dimensioni per i test di integrazione

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

2

Ho il seguente requisito per un'applicazione:

Archivia grandi file (ordine di megabyte) che utilizzerò come input per il test di non regressione e alcune proprietà previste del risultato di elaborazione
Permetti agli utenti aziendali di aggiungere ulteriori file e proprietà
Essere in grado di monitorare nel tempo quali file (e proprietà) sono stati utilizzati per testare

Ovviamente inserire i dati di test in VCS non consentirebbe agli utenti aziendali di aggiungere facilmente file e proprietà, dovrei utilizzare un cloud storage? Quali altre soluzioni ho?

integration-tests storage

posta Edmondo1984 01.06.2016 - 09:31

fonte

2 risposte

Leggi altre domande sui tag integration-tests storage

Domanda concettuale riguardante la portabilità di un software da desktop a mobile Strutture dati orientate agli oggetti in applicazioni basate su database

score 3 · Answer 1

Direi che lo vuoi in VCS.

Quando si dirama o tagghi il codice, vuoi anche diramare / taggare i tuoi test. E con questo i tuoi dati di test. Altrimenti, come fai a sapere quale set di dati si lega con quale particolare set di codici hai.

Si potrebbe eventualmente contenere un riferimento a un set di dati all'interno della propria base di codici con versione e memorizzare all'esterno il dataset effettivo. Quindi i tuoi test avrebbero un dataset di riferimento da caricare e potresti cambiarlo con ogni branch o tag. Ma ciò sembra particolarmente problematico e difficile da mantenere, e vorrei evitarlo, se possibile.

score 1 · Answer 2

Obviously putting the test data under VCS wouldn't work

Perché no? E che dire di LFS ?

Anche senza LFS, è necessario pensarci due volte prima di scartare la soluzione di controllo della versione. Dici solo che ci sono alcuni file che hanno una dimensione di pochi megabyte. Nessuna ulteriore indicazione.

Una dozzina di file da 5 MB che cambiano una volta al mese per un progetto di 12 mesi non è un grosso problema: qualsiasi controllo di versione lo gestirà in modo indolore.
Centinaia di file di 5 MB modificati quasi quotidianamente per un progetto di 2 anni potrebbero portare alcuni sistemi di controllo di versioni / server / reti e richiedere una preparazione aggiuntiva.

Se sei nel primo caso, crea semplicemente un repository dedicato usando il tuo sistema di controllo delle versioni preferito.

Se sei nel secondo caso, devi essere molto specifico: quanti file? Con quale frequenza vengono cambiati? Qual'è la dimensione media esatta? Quanto è lungo il progetto? Da lì, puoi utilizzare una soluzione esistente, come LFS, o crearne una tua, in cui i file verranno effettivamente archiviati su un NAS, ma non saranno mai accessibili direttamente, ma solo attraverso il controllo della versione personalizzata.

Se ti trovi nel mondo Microsoft, la funzionalità FILESTREAM di Microsoft SQL Server potrebbe aiutare a sottrarre l'effettiva archiviazione dei file. Alla fine (anche se non conosco abbastanza bene Microsoft SQL Server), potresti essere in grado di combinarlo con CDC per tracciare le modifiche effettive. Inoltre, SharePoint ti offre la possibilità di eseguire il versioning dei file binari mentre li memorizzi efficientemente se solo una parte di un file binario viene effettivamente modificata.