Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Database Dashboard VTS

Per supportare un dashboard di integrazione continua che sia scalabile, performante e flessibile, il backend del Dashboard di VTS deve essere progettato con cura con una solida conoscenza della funzionalità del database. Google Cloud Datastore è un database NoSQL che offre garanzie ACID transazionali ed eventuale coerenza nonché una forte coerenza all'interno dei gruppi di entità. Tuttavia, la struttura è molto diversa dai database SQL (e persino 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 la creazione di un backend efficace per il servizio Web Dashboard VTS.

Entità

Le seguenti entità memorizzano riepiloghi e risorse dalle esecuzioni di test VTS:

  • Entità di prova . Memorizza i metadati relativi alle esecuzioni di test di un determinato test. La chiave è il nome del test e le sue proprietà includono il conteggio degli errori, il conteggio dei passaggi e l'elenco delle rotture del test case da quando i lavori di avviso lo aggiornano.
  • Test Run Entity . Contiene metadati dalle esecuzioni di un determinato test. Deve memorizzare i timestamp di inizio e fine del test, l'ID di build del test, il numero di casi di test superati e non riusciti, il tipo di esecuzione (ad esempio pre-invio, post-invio o locale), un elenco di collegamenti di log, l'host il nome della macchina e il riepilogo della copertura contano.
  • Entità di informazioni sul dispositivo . Contiene dettagli sui dispositivi utilizzati durante l'esecuzione del test. Include l'ID di build del dispositivo, il nome del prodotto, il target di build, la filiale e le informazioni ABI. Questo viene archiviato separatamente dall'entità di esecuzione test per supportare le esecuzioni di test multi-dispositivo in modo uno-a-molti.
  • Entità di esecuzione del punto di profilatura . Riassume i dati raccolti per un particolare punto di profilazione all'interno di una corsa di prova. Descrive le etichette degli assi, il nome del punto di profilatura, i valori, il tipo e la modalità di regressione dei dati di profilatura.
  • Entità 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.
  • Test Case Run Entity . Descrive il risultato di un particolare caso di test da un'esecuzione del test, incluso il nome del caso di test e il suo 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 una query bidirezionale efficiente (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à della corsa di prova sono sia figli di questo gruppo che genitori di entità dispositivo, entità dei punti di profilazione ed entità di copertura rilevanti per il rispettivo antenato della prova e della prova.

Figura 1 Antenati dell'entità test.

Punto chiave: quando si progettano relazioni ancestrali, è 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 a quando non viene commessa e che le transazioni in passato sono visibili alle operazioni attuali. In Cloud Datastore, il raggruppamento di entità crea isole di forte coerenza in lettura e scrittura all'interno del gruppo, che in questo caso comprende 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 lavori di avviso possono essere trattati come atomici
  • Visualizzazione coerente garantita dei risultati del test case all'interno dei moduli di test
  • Interrogazioni più rapide all'interno di alberi di origine

limitazioni

La scrittura su un gruppo di entità a una velocità superiore a un'entità al secondo non è consigliata 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 di una scrittura per modulo di test al secondo è ragionevole perché le esecuzioni di test richiedono in genere almeno un minuto incluso il sovraccarico del framework VTS; a meno che un test non venga costantemente 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 richiede più di un'ora. Le anomalie possono essere facilmente gestite se gli host eseguono i test contemporaneamente, causando brevi scoppi di scritture sugli stessi host (ad esempio rilevando errori di scrittura e riprovando).

Considerazioni sul ridimensionamento

Un'esecuzione di test non deve necessariamente avere il test come genitore (ad es. Potrebbe richiedere qualche altra chiave e avere il nome del test, l'ora di inizio del test come proprietà); tuttavia, questo cambierà una forte coerenza con un'eventuale coerenza. 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 di esecuzioni di test. Ciò può 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 l'istantanea sarà coerente, ma non ci sono garanzie che saranno i dati 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 di scrittura massimo all'interno di un gruppo di entità di uno al secondo, insieme a una dimensione di transazione massima di 500 entità.

Un approccio sarebbe quello di specificare un caso di test che ha un test eseguito come antenato (simile a come vengono archiviati i dati di copertura, i dati di profilazione e le informazioni sul dispositivo):

Figura 2 I casi di test scendono dalle prove (NON CONSIGLIATO).

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 (presupponendo che non vi siano dati di copertura o profilazione). Se un test dovesse superare questo, una singola transazione non potrebbe scrivere tutti i risultati del test case in una sola volta e dividere i casi di test in transazioni separate potrebbe superare la velocità massima di scrittura del gruppo di entità di una iterazione al secondo. Poiché questa soluzione non si ridimensionerà bene senza sacrificare le prestazioni, non è consigliabile.

Tuttavia, invece di archiviare i risultati del test case come elementi secondari dell'esecuzione del test, i casi di test 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 entità dei casi di test):

Figura 3 Casi di test memorizzati in modo indipendente (CONSIGLIATO).

A prima vista, questo può sembrare infrangere la forte garanzia di coerenza. Tuttavia, se il client ha un'entità di esecuzione test e un elenco di identificatori di casi di test, non è necessario creare una query; può invece ottenere direttamente i casi di test dai loro identificatori, che è sempre garantito che siano coerenti. Questo approccio allevia enormemente il vincolo sul numero di casi di test che può avere una serie di test acquisendo una forte coerenza senza minacciare una scrittura eccessiva all'interno di un gruppo di entità.

Schemi di accesso ai dati

Il dashboard VTS utilizza i seguenti modelli di accesso ai dati:

  • Preferiti dell'utente . È possibile eseguire una query utilizzando un filtro di uguaglianza sulle entità preferite dell'utente con l'oggetto Utente specifico App Engine come proprietà.
  • Elenco di prova . Interrogazione semplice di entità di test. Per ridurre la larghezza di banda per il rendering della home page, è possibile utilizzare una proiezione sui conteggi di passaggi e errori in modo da omettere l'elenco potenzialmente lungo di ID di casi di test non riusciti e altri metadati utilizzati dai lavori di avviso.
  • Esecuzioni di test . La query per le entità dell'esecuzione del test richiede un ordinamento sulla chiave (timestamp) e un possibile filtro sulle proprietà dell'esecuzione del test come ID build, conteggio passaggi, ecc. Eseguendo una query antenata con una chiave dell'entità test, la lettura è fortemente coerente. A questo punto, tutti i risultati del test case possono essere recuperati utilizzando l'elenco di ID memorizzati in una proprietà di esecuzione test; anche questo è garantito per essere un risultato fortemente coerente per la natura delle operazioni di acquisizione dei datastore.
  • Dati di profilazione e copertura . È possibile eseguire query per la profilazione o i dati di copertura associati a un test senza recuperare anche altri dati dell'esecuzione del test (come altri dati di profilazione / copertura, dati del test case, ecc.). Una query antenata che utilizza il test test e le chiavi dell'entità dell'esecuzione del test recupererà tutti i punti di profilatura registrati durante l'esecuzione del test; filtrando anche il nome del punto di profilatura o il nome file, è possibile recuperare una singola entità di profilazione o copertura. Per natura delle domande degli antenati, questa operazione è fortemente coerente.

Per i dettagli sull'interfaccia utente e le schermate di questi schemi di dati in azione, vedere UI Dashboard DTS .