Per supportare un dashboard di integrazione continua che sia scalabile, performante e flessibile, il backend VTS Dashboard deve essere progettato attentamente con una profonda conoscenza delle funzionalità del database. Google Cloud Datastore è un database NoSQL che offre garanzie ACID transazionali e coerenza finale, nonché una forte coerenza all'interno dei gruppi di entità. Tuttavia, la struttura è molto diversa da quella dei database SQL (e anche da Cloud Bigtable); invece di tabelle, righe e celle ci sono tipi, entità e proprietà.
Le sezioni seguenti descrivono la struttura dei dati e i modelli di query per creare un backend efficace per il servizio web VTS Dashboard.
Entità
Le seguenti entità archiviano riepiloghi e risorse dalle esecuzioni dei test VTS:
- Entità di prova . Memorizza i metadati sulle esecuzioni di test di un particolare test. La sua chiave è il nome del test e le sue proprietà includono il conteggio degli errori, il conteggio dei passaggi superati e l'elenco delle interruzioni del test case da quando i processi di avviso lo aggiornano.
- Entità esecuzione test . Contiene i metadati delle esecuzioni di un test particolare. Deve memorizzare i timestamp di inizio e fine del test, l'ID della build del test, il numero di casi di test superati e falliti, il tipo di esecuzione (ad esempio pre-invio, post-invio o locale), un elenco di collegamenti di registro, l'host nome della macchina e conteggi di riepilogo della copertura.
- Entità delle informazioni sul dispositivo . Contiene dettagli sui dispositivi utilizzati durante l'esecuzione del test. Include l'ID build del dispositivo, il nome del prodotto, la destinazione della build, il ramo e le informazioni ABI. Questo viene archiviato separatamente dall'entità di esecuzione del test per supportare le esecuzioni di test multi-dispositivo in modalità uno-a-molti.
- Entità esecuzione punto di profilazione . Riepiloga i dati raccolti per un particolare punto di profilazione all'interno di un'esecuzione di test. Descrive le etichette degli assi, il nome del punto di profilatura, i valori, il tipo e la modalità di regressione dei dati di profilatura.
- Ente di copertura . Descrive i dati di copertura raccolti per un file. Contiene le informazioni sul progetto Git, il percorso del file e l'elenco dei conteggi di copertura per riga nel file di origine.
- Entità di esecuzione del caso di test . Descrive il risultato di un particolare test case da un'esecuzione di test, incluso il nome del test case e il relativo risultato.
- Entità Preferiti utente . Ogni abbonamento utente può essere rappresentato in un'entità contenente un riferimento al test e l'ID utente generato dal servizio utente di App Engine. Ciò consente un'efficiente interrogazione bidirezionale (vale a dire per tutti gli utenti iscritti a un test e per tutti i test preferiti da un utente).
Raggruppamento di entità
Ogni modulo di test rappresenta la radice di un gruppo di entità. Le entità dell'esecuzione di test sono sia figli di questo gruppo che genitori per entità dispositivo, entità punto di profilazione ed entità di copertura rilevanti per il rispettivo test e antenato dell'esecuzione di test.
Punto chiave: quando si progettano relazioni di ascendenza, è necessario bilanciare la necessità di fornire meccanismi di interrogazione efficaci e coerenti con le limitazioni imposte dal database.
Benefici
Il requisito di coerenza garantisce che le operazioni future non vedranno gli effetti di una transazione fino al commit e che le transazioni passate siano visibili alle operazioni presenti. In Cloud Datastore, il raggruppamento di entità crea isole di elevata coerenza di lettura e scrittura all'interno del gruppo, che in questo caso sono tutte le esecuzioni di test e i dati relativi a un modulo di test. Ciò offre i seguenti vantaggi:
- Le letture e gli aggiornamenti allo stato del modulo di test da parte dei processi di avviso possono essere trattati come atomici
- Visualizzazione coerente garantita dei risultati dei casi di test all'interno dei moduli di test
- Interrogazioni più veloci all'interno degli alberi genealogici
Limitazioni
Non è consigliabile scrivere su un gruppo di entità a una velocità superiore a un'entità al secondo poiché alcune scritture potrebbero essere rifiutate. Finché i lavori di avviso e il caricamento non avvengono a una velocità superiore a una scrittura al secondo, la struttura è solida e garantisce una forte coerenza.
In definitiva, il limite massimo di una scrittura per modulo di test al secondo è ragionevole perché l'esecuzione dei test solitamente richiede almeno un minuto compreso il sovraccarico del framework VTS; a meno che un test non venga eseguito simultaneamente su più di 60 host diversi, non può esserci un collo di bottiglia in scrittura. Ciò diventa ancora più improbabile dato che ogni modulo fa parte di un piano di test che spesso dura più di un'ora. Le anomalie possono essere facilmente gestite se gli host eseguono i test nello stesso momento, causando brevi raffiche di scritture sugli stessi host (ad esempio rilevando errori di scrittura e riprovando).
Considerazioni sulla scalabilità
L'esecuzione di un test non deve necessariamente avere il test come genitore (ad esempio potrebbe prendere qualche altra chiave e avere il nome del test e l'ora di inizio del test come proprietà); tuttavia, ciò scambierà una forte coerenza con una coerenza finale. Ad esempio, il processo di avviso potrebbe non visualizzare un'istantanea reciprocamente coerente delle esecuzioni di test più recenti all'interno di un modulo di test, il che significa che lo stato globale potrebbe non rappresentare una rappresentazione completamente accurata della sequenza delle esecuzioni di test. Ciò potrebbe anche influire sulla visualizzazione delle esecuzioni di test all'interno di un singolo modulo di test, che potrebbe non essere necessariamente un'istantanea coerente della sequenza di esecuzione. Alla fine lo snapshot sarà coerente, ma non vi è alcuna garanzia che i dati siano più aggiornati.
Casi test
Un altro potenziale collo di bottiglia sono i test di grandi dimensioni con molti casi di test. I due vincoli operativi sono il throughput massimo di scrittura all'interno di un gruppo di entità di uno al secondo, insieme a una dimensione massima della transazione di 500 entità.
Un approccio potrebbe essere quello di specificare un caso di test che abbia un'esecuzione di test come antenato (simile a come vengono archiviati i dati di copertura, i dati di profilazione e le informazioni sul dispositivo):
Sebbene questo approccio offra atomicità e coerenza, impone forti limitazioni ai test: se una transazione è limitata a 500 entità, un test non può avere più di 498 casi di test (assumendo nessuna copertura o dati di profilazione). Se un test dovesse superare questo limite, una singola transazione non potrebbe scrivere tutti i risultati del test case in una volta e la divisione dei test case in transazioni separate potrebbe superare il throughput massimo di scrittura del gruppo di entità di un'iterazione al secondo. Poiché questa soluzione non è scalabile bene senza sacrificare le prestazioni, non è consigliata.
Tuttavia, invece di memorizzare i risultati dei test case come figli dell'esecuzione del test, i test case possono essere archiviati in modo indipendente e le relative chiavi fornite all'esecuzione del test (un'esecuzione del test contiene un elenco di identificatori per le sue entità dei test case):
A prima vista, ciò potrebbe sembrare infrangere la forte garanzia di coerenza. Tuttavia, se il client dispone di un'entità di esecuzione del test e di un elenco di identificatori del test case, non è necessario costruire una query; può invece ottenere direttamente i casi di test tramite i loro identificatori, il che è sempre garantito che sia coerente. Questo approccio allevia notevolmente il vincolo sul numero di casi di test che un'esecuzione di test può avere, ottenendo allo stesso tempo una forte coerenza senza minacciare un'eccessiva scrittura all'interno di un gruppo di entità.
Modelli di accesso ai dati
Il dashboard VTS utilizza i seguenti modelli di accesso ai dati:
- Preferiti dell'utente . È possibile eseguire query utilizzando un filtro di uguaglianza sulle entità preferite dall'utente che hanno come proprietà lo specifico oggetto Utente di App Engine.
- Elenco di prova . Semplice query di entità di test. Per ridurre la larghezza di banda per il rendering della home page, è possibile utilizzare una proiezione sui conteggi positivi e negativi in modo da omettere l'elenco potenzialmente lungo degli ID dei test case non riusciti e altri metadati utilizzati dai processi di avviso.
- Esecuzioni di prova . L'esecuzione di query per le entità dell'esecuzione del test richiede un ordinamento sulla chiave (timestamp) e un possibile filtraggio sulle proprietà dell'esecuzione del test come ID build, conteggio dei passaggi, ecc. Eseguendo una query sull'antenato con una chiave dell'entità di test, la lettura è fortemente coerente. A questo punto, tutti i risultati del test case possono essere recuperati utilizzando l'elenco di ID archiviati in una proprietà di esecuzione del test; anche questo è garantito come risultato fortemente coerente data la natura delle operazioni di acquisizione del datastore.
- Dati di profilazione e copertura . È possibile eseguire query per dati di profilazione o copertura associati a un test senza recuperare anche altri dati di esecuzione del test (come altri dati di profilazione/copertura, dati di test case, ecc.). Una query antenato che utilizza le chiavi dell'entità test test ed esecuzione del test recupererà tutti i punti di profilatura registrati durante l'esecuzione del test; filtrando anche in base al nome del punto di profilazione o al nome del file è possibile recuperare un'unica entità di profilazione o di copertura. Per la natura delle query sugli antenati, questa operazione è fortemente coerente.
Per dettagli sull'interfaccia utente e schermate di questi modelli di dati in azione, vedere Interfaccia utente di VTS Dashboard .