Aby zapewnić obsługę dashboardu ciągłej integracji, który jest skalowalny, wydajny i elastyczny, backend VTS Dashboard musi być starannie zaprojektowany z uwzględnieniem funkcjonalności bazy danych. Google Cloud Datastore to baza danych NoSQL oferująca transakcyjne gwarancje ACID i ostateczną spójność, a także silną spójność w obrębie grup podmiotów. Jednak struktura znacznie różni się od baz danych SQL (a nawet Cloud Bigtable); zamiast tabel, wierszy i komórek istnieją rodzaje, jednostki i właściwości.
W poniższych sekcjach omówiono strukturę danych i wzorce zapytań umożliwiające utworzenie efektywnego backendu dla usługi internetowej VTS Dashboard.
Podmioty
Następujące podmioty przechowują podsumowania i zasoby z przebiegów testowych VTS:
- Jednostka testowa . Przechowuje metadane dotyczące przebiegów testowych określonego testu. Jego kluczem jest nazwa testu, a jego właściwości obejmują liczbę niepowodzeń, liczbę zaliczonych testów i listę uszkodzeń przypadków testowych od momentu aktualizacji go przez zadania alertów.
- Jednostka uruchomienia testowego . Zawiera metadane z przebiegów określonego testu. Musi przechowywać znaczniki czasu rozpoczęcia i zakończenia testu, identyfikator kompilacji testu, liczbę przypadków testowych, które zakończyły się sukcesem i niepowodzeniem, typ przebiegu (np. przed przesłaniem, po przesłaniu lub lokalnie), listę łączy do dziennika, host liczy się nazwa komputera i podsumowanie zasięgu.
- Jednostka informacji o urządzeniu . Zawiera szczegółowe informacje o urządzeniach używanych podczas przebiegu testowego. Zawiera identyfikator kompilacji urządzenia, nazwę produktu, cel kompilacji, oddział i informacje ABI. Są one przechowywane oddzielnie od jednostki przebiegu testu, aby obsługiwać przebiegi testów na wielu urządzeniach w sposób „jeden do wielu”.
- Element przebiegu punktu profilowania . Podsumowuje dane zebrane dla konkretnego punktu profilowania w ramach przebiegu testowego. Opisuje etykiety osi, nazwę punktu profilowania, wartości, typ i tryb regresji danych profilowania.
- Podmiot objęty ubezpieczeniem . Opisuje dane dotyczące zasięgu zebrane dla jednego pliku. Zawiera informacje o projekcie Git, ścieżkę pliku i listę liczników pokrycia w wierszu pliku źródłowego.
- Jednostka uruchamiania przypadku testowego . Opisuje wynik konkretnego przypadku testowego z przebiegu testu, łącznie z nazwą przypadku testowego i jego wynikiem.
- Jednostka Ulubione użytkownika . Każda subskrypcja użytkownika może być reprezentowana w encji zawierającej odniesienie do testu i identyfikator użytkownika wygenerowany z usługi użytkownika App Engine. Pozwala to na efektywne wysyłanie zapytań dwukierunkowych (tj. o wszystkich użytkowników zapisanych do testu i o wszystkie testy dodane przez użytkownika do ulubionych).
Grupowanie jednostek
Każdy moduł testowy reprezentuje katalog główny grupy jednostek. Jednostki przebiegu testu są zarówno elementami podrzędnymi tej grupy, jak i elementami nadrzędnymi dla jednostek urządzeń, jednostek punktów profilowania i jednostek pokrycia odpowiednich dla odpowiedniego przodka testu i przebiegu testu.
Kluczowy punkt: Projektując relacje przodków, należy zrównoważyć potrzebę zapewnienia skutecznych i spójnych mechanizmów zapytań z ograniczeniami narzucanymi przez bazę danych.
Korzyści
Wymóg spójności gwarantuje, że przyszłe operacje nie zobaczą skutków transakcji, dopóki nie zostanie ona zatwierdzona, a transakcje z przeszłości będą widoczne dla obecnych operacji. W Cloud Datastore grupowanie encji tworzy w grupie wyspy o dużej spójności odczytu i zapisu, którymi w tym przypadku są wszystkie przebiegi testów i dane powiązane z modułem testowym. Zapewnia to następujące korzyści:
- Odczyty i aktualizacje stanu modułu testowego przez zadania alertów można traktować jako niepodzielne
- Gwarantowany spójny widok wyników przypadków testowych w modułach testowych
- Szybsze wykonywanie zapytań w obrębie drzew przodków
Ograniczenia
Nie zaleca się zapisywania do grupy jednostek z szybkością większą niż jedna jednostka na sekundę, ponieważ niektóre zapisy mogą zostać odrzucone. Dopóki zadania alertów i przesyłanie nie odbywają się z szybkością większą niż jeden zapis na sekundę, struktura jest solidna i gwarantuje dużą spójność.
Ostatecznie ograniczenie jednego zapisu na moduł testowy na sekundę jest rozsądne, ponieważ przebiegi testów zwykle zajmują co najmniej jedną minutę, włączając obciążenie środowiska VTS; o ile test nie jest konsekwentnie wykonywany jednocześnie na więcej niż 60 różnych hostach, nie może wystąpić wąskie gardło w zapisie. Staje się to tym bardziej mało prawdopodobne, biorąc pod uwagę, że każdy moduł jest częścią planu testów, który często trwa dłużej niż godzinę. Anomalie można łatwo rozwiązać, jeśli hosty uruchamiają testy w tym samym czasie, powodując krótkie serie zapisów na tych samych hostach (np. poprzez wychwytywanie błędów zapisu i ponowną próbę).
Rozważania dotyczące skalowania
Przebieg testu niekoniecznie musi mieć test jako swojego rodzica (np. może przyjąć inny klucz i mieć nazwę testu, czas rozpoczęcia testu jako właściwości); jednakże spowoduje to zamianę silnej spójności na ostateczną spójność. Na przykład zadanie alertu może nie widzieć wzajemnie spójnej migawki najnowszych przebiegów testów w module testowym, co oznacza, że stan globalny może nie odzwierciedlać w pełni dokładnej reprezentacji sekwencji przebiegów testów. Może to również mieć wpływ na wyświetlanie przebiegów testów w ramach pojedynczego modułu testowego, co niekoniecznie musi stanowić spójną migawkę sekwencji uruchomień. Ostatecznie migawka będzie spójna, ale nie ma gwarancji, że będą to najświeższe dane.
Przypadki testowe
Kolejnym potencjalnym wąskim gardłem są duże testy z wieloma przypadkami testowymi. Dwa ograniczenia operacyjne to maksymalna przepustowość zapisu w grupie jednostek wynosząca jeden na sekundę oraz maksymalny rozmiar transakcji wynoszący 500 jednostek.
Jednym z podejść byłoby określenie przypadku testowego, którego przodkiem jest przebieg testu (podobnie jak przechowywane są dane dotyczące zasięgu, dane profilowania i informacje o urządzeniu):
Chociaż to podejście zapewnia atomowość i spójność, nakłada poważne ograniczenia na testy: jeśli transakcja jest ograniczona do 500 jednostek, wówczas test może obejmować nie więcej niż 498 przypadków testowych (zakładając, że nie ma danych pokrycia ani profilowania). Jeśli test przekroczy tę wartość, wówczas pojedyncza transakcja nie będzie w stanie zapisać wszystkich wyników przypadków testowych na raz, a podzielenie przypadków testowych na osobne transakcje może przekroczyć maksymalną przepustowość zapisu grupy jednostek wynoszącą jedną iterację na sekundę. Ponieważ to rozwiązanie nie będzie dobrze skalowalne bez utraty wydajności, nie jest zalecane.
Jednak zamiast przechowywać wyniki przypadków testowych jako elementy podrzędne przebiegu testu, przypadki testowe mogą być przechowywane niezależnie, a ich klucze dostarczane do przebiegu testu (przebieg testu zawiera listę identyfikatorów jednostek przypadków testowych):
Na pierwszy rzut oka może się to wydawać naruszeniem silnej gwarancji spójności. Jeśli jednak klient ma jednostkę uruchamiającą test i listę identyfikatorów przypadków testowych, nie musi konstruować zapytania; zamiast tego może bezpośrednio uzyskać przypadki testowe według ich identyfikatorów, co zawsze gwarantuje spójność. Takie podejście znacznie łagodzi ograniczenia dotyczące liczby przypadków testowych, jakie może obejmować przebieg testu, jednocześnie uzyskując dużą spójność bez grożenia nadmiernemu zapisywaniu w grupie jednostek.
Wzorce dostępu do danych
W Panelu VTS Dashboard stosowane są następujące schematy dostępu do danych:
- Ulubione użytkownika . Można o to zapytać, używając filtra równości dla ulubionych jednostek użytkownika mających konkretny obiekt użytkownika App Engine jako właściwość.
- Lista testów . Proste zapytanie o jednostki testowe. Aby zmniejszyć przepustowość podczas renderowania strony głównej, można zastosować projekcję w przypadku zliczeń zakończonych sukcesem i błędami, aby pominąć potencjalnie długą listę identyfikatorów przypadków testowych, które zakończyły się niepowodzeniem, oraz innych metadanych używanych przez zadania alertów.
- Uruchomienia testowe . Zapytanie o jednostki przebiegu testu wymaga sortowania według klucza (sygnatury czasowej) i możliwego filtrowania według właściwości przebiegu testu, takich jak identyfikator kompilacji, liczba przekazań itp. Dzięki wykonaniu zapytania przodka z kluczem jednostki testowej odczyt jest bardzo spójny. W tym momencie można pobrać wszystkie wyniki przypadków testowych, korzystając z listy identyfikatorów przechowywanych we właściwości przebiegu testu; gwarantuje to również bardzo spójny wynik ze względu na charakter operacji pobierania magazynu danych.
- Dane profilowania i pokrycia . Zapytanie o dane dotyczące profilowania lub pokrycia powiązane z testem można wykonać bez pobierania jakichkolwiek innych danych przebiegu testu (takich jak inne dane profilowania/pokrycia, dane przypadku testowego itp.). Zapytanie nadrzędne wykorzystujące klucze jednostki testu testowego i przebiegu testu pobierze wszystkie punkty profilowania zarejestrowane podczas przebiegu testu; filtrując również nazwę punktu profilowania lub nazwę pliku, można pobrać pojedynczą jednostkę profilowania lub pokrycia. Ze względu na naturę zapytań dotyczących przodków operacja ta jest silnie spójna.
Aby uzyskać szczegółowe informacje na temat interfejsu użytkownika i zrzutów ekranu tych wzorców danych w działaniu, zobacz Interfejs użytkownika pulpitu nawigacyjnego VTS .