Próby na koncie wyczyszczonym pomijają ważną wadę
Nowa budowa Unity może wyglądać doskonale, gdy zaczyna się z pustym profilem. Świeże konto nie ma emerytowanych pól, pół ukończone questy, cached odniesienia katalogowe, stare stosy zapasów, przerywane zakupy, lub wartości, które były ważne w ramach wcześniejszego zbioru zasad. Dlatego dowodzi tylko, że nowy format może stworzyć nowy stan. Mówi bardzo niewiele o tym, czy gra może bezpiecznie przenieść gracza z wczorajszego świata do dzisiejszego.
Migracja powinna rozpocząć się od silniejszego pytania: czy to dokładne historyczne państwo może wejść do obecnej budowy, zachować znaczenie, które nadal ma znaczenie, i albo stać się aktualnym stanem lub nie w sposób, który jest przydatny do diagnozowania? Jest to pytanie o produkt tak samo jak pytanie serializer. Pole może dezercjalizować pomyślnie podczas nadal naruszania zasady progresji, wskazując na brakujące treści, lub zmiany uprawnienia do zakupu. Wczytywanie bajtów nie wystarczy.
Ten artykuł opisuje proces local- pierwszy próbny. Celowo nie jest obietnicą, że jedno narzędzie może zrozumieć każdą konfigurację serializacyjną Unity, backend lub integrację platformy. Modele danych Unity różnią się, a gra może dodać własne szyfrowanie, synchronizacja chmur, format binarny lub niestandardowe adaptery. Trwałą częścią jest dyscyplina testowa: zachować kształty historyczne, skopiować je przed mutacją, uczynić ścieżkę migracyjną wyraźną, i sprawdzić invariants gry po każdej granicy.
Zbuduj historyczny korpus państwowy
Traktuj stary oszczędza jako versioned corpus, a nie jako luźne pliki przekazywane w czacie. Każda instalacja potrzebuje stabilnego identyfikatora, wersji, która go wyprodukowała, krótkiej etykiety scenariusza, deklaracji formatu i klasyfikacji prywatności. Etykieta scenariusza ma znaczenie, ponieważ pakiet migracyjny powinien zawierać znaczące stany, a nie tylko przypadkowe JSON. Przykłady obejmują nowego gracza, gracza na granicy rozdziału, inwentarz na jego limit stosu, przerwany tutorial, stary event nagrody, użytkownik z opcjonalną zawartością kosmetyczną, a profil, który celowo zawiera nieprawidłową kombinację spuścizny.
Użyj niezmiennych kopii roboczych. Biegacz testowy nie powinien nigdy nadpisywać utrwalacza źródłowego podczas próby migracji. Skopiuj go do tymczasowego katalogu roboczego, napisz jego sumę kontrolną lub zawartość hash, uruchom adapter i zachowaj uzyskany wynik oddzielnie. To zamienia zaskakujący wynik w dowód, że ktoś inny może powtórzyć. To również zapobiega testowi, aby po cichu poprawić swoje własne wejście, dopóki oryginalny problem nie zniknie.
Zachować dane gracza produkcji z ogólnego katalogu utrwalenia rozwoju. Historyczny korpus może być syntetyczny, zgoda, starannie zredagowane, lub generowane ze scenariuszy deterministycznych. Kluczem jest to, że zachowuje strukturalne i semantyczne przypadki krawędzi, które mają znaczenie. Prywatność nie jest po myśli: usunąć bezpośrednie identyfikatory, identyfikatory urządzeń, dane kontaktowe, żetony płatności, surowe wpływy i tajemnice, zanim urządzenie staje się szeroko dostępne.
Narysuj wykres migracji przed napisaniem konwertera
Numery wersji nie są planem migracji. Gra może przenieść się z 1 do 2, 2 do 3oraz 3 do 4, następnie spotkać gracza, który opuścił bezpośrednio z 1 do 4. Może wysłać hotfix, który zmienia tylko zagnieżdżony rekord inwentaryzacji, lub przejść na emeryturę pole, które stara zawartość nadal oczekuje. Wykres sprawia, że te wybory widoczne: każdy węzeł jest zapisać schemat lub wersja semantyczna; każda krawędź jest wyraźną transformacją lub zamierzonym odrzuceniem; każda krawędź ma warunki wstępne i warunki postconditions.
Dla każdej obsługiwanej wersji startowej, zdecydować, czy łańcuchy gry sąsiadujące transformacje, używa bezpośredniej transformacji, lub wymaga aktualizacji po stronie usługi przed obciążeniem klienta. Nie pozostawić pominięte wersje do cokolwiek dzieje się, gdy pola są nieobecne. Łańcuch może być bezpieczniejszy, gdy każdy krok jest mały i przetestowany. Bezpośrednia transformacja może być bezpieczniejsza, gdy formaty pośrednie nigdy nie były przeznaczone do obserwacji. Oba podejścia wymagają wyraźnej własności i powtarzalne mocowania.
Graf powinien zawierać więcej niż zserializowany typ. Zapisuj zależności katalogowe zawartości, wersje konfiguracyjne, flagi funkcji, które wpływają na interpretację, oraz bieżącą wersję aplikacji. Zapis może być synchronicznie aktualny, ale niepoprawny, ponieważ element odniesienia nie istnieje lub reguła zmieniła znaczenie. Są to granice kompatybilności, a nie irytujące przypadki krawędzi.
Dodać Save- load okrągłe wycieczki obserwowalne
Po wejściu urządzenia do ścieżki migracyjnej, wykonać pełną podróż w obie strony: załadować historyczne wejście, migrację, zbudować model in- game, zapisać go przy użyciu aktualnego pisarza, a następnie załadować ten prąd wyjściowy ponownie. Pierwsze obciążenie sprawdza, czy rekord historyczny może wejść do systemu. Drugie obciążenie sprawdza, czy obecny pisarz stworzył stabilny, samowystarczalny wynik. Porównaj stan po pierwszym i drugim obciążeniu zgodnie z zasadami semantycznymi, nie tylko surowej równości bajtów.
Równość Surowa jest często błędne twierdzenie. Nowe domyślne mogą być dodawane, zamówienie pola może się zmienić, znaczniki czasu mogą być odświeżone, a zbiory mogą otrzymywać stabilne zamówienie. Zdefiniuj standaryzator dla wartości, które są celowo non-semantic, a następnie porównać resztę. Normalizator sam zasługuje na recenzję; nie może stać się kocem ignorować listę, która ukrywa prawdziwą stratę. Dobre raporty porównawcze, które pola zostały dodane, usunięte, przekształcone lub celowo zignorowane.
Wynik testu powinien nazwać pierwszy niepoprawny stan. Jeśli łańcuch migracji ma trzy przejścia, nie raportuj tylko, że końcowe obciążenie nie powiodło się. Uchwyć stan po każdym punkcie kontrolnym, potwierdzić go, i zatrzymać się na najwcześniejszej granicy, która narusza niezmiennego. Ta lokalizacja przekształca niejasny "stary zapisać złamany" raport do określonej krawędzi migracji, oprawy i różnicy stanu.
Specyficzne dla gier ekspresowych invariants
Ogólna uprzęża migracyjna nie może wiedzieć, co oznacza progresja w danej grze. Gra musi zapewnić własnych niezmienników. Napisz je w języku, który łączy się z wynikami gracza: poziom jest w bieżącym zakresie; ilość inwentaryzacji jest nie-ujemna i ograniczona; każdy przedmiot posiada znaną definicję lub jawne spadki spuścizny; ukończony tutorial pozostaje ukończony; waluta jest skończona; referencja quest należy do bieżącego katalogu; uprawnienie jest unikalne; światowy materiał siewny i generowane państwo światowe zgadzają się.
Oddzielne invariants do warstw. Strukturalni invariants odpowiadają na to, czy wymagane pola i typy istnieją. Referencyjne invariants odpowiadają na to, czy identyfikatory wskazują na znane definicje. Invariants domeny odpowiadają na to, czy wartości są zgodne z zasadami gry. Invarianci bezpieczeństwa odpowiadają na to, czy dane są skończone, ograniczone i bezpieczne do wyświetlania. Gdy oprawa nie działa, warstwa informuje zespół, czy potrzebuje zmiany serializatora, adaptera katalogowego, decyzji regulatora, czy też polityki odzyskiwania.
Użyj deterministycznych mutacji, aby korpus pracował ciężej. Zacznij od znanego uchwytu i celowo usunąć pole, powielić ID inwentaryzacji, zastąpić odniesienie katalogu, pominąć wersję, zmienić porządek listy działań, lub zmienić ilość graniczną. Każda mutacja powinna mieć oczekiwany wynik: migrate z udokumentowanym domyślnym, odrzucić z kategorii diagnostycznej, kwarantanna do odzysku, lub wymagają własnej zatwierdzonej naprawy danych. "Nie rozbija się" nie jest wystarczającym oczekiwanym wynikiem.
Zmniejsz niepowodzenie zapisu bez utraty błędu
Jeśli oprawa zawiera setki pól i migracja nie powiodła się, developer może spędzić godziny czytając niepowiązane dane. Znaczna minimalizacja zmniejsza oprawę przy zachowaniu naruszonego niezmienności. Usuń grupę pól, ponownie spróbować tej samej migracji deterministycznej, i zachować usunięcie tylko wtedy, gdy nadal występuje niepowodzenie. Następnie kolekcje partycji, zmniejszyć wartości w kierunku granic i zmniejszyć historię akcji, jeśli ma znaczenie powtórne zachowanie.
Redukcja wymaga odtwarzalności. Zablokuj hasz montażowy, wersję migracyjną, wersję adaptera, nasienie deterministyczne, odpowiednie migawki konfiguracyjne i spodziewane niezmienność. Jeśli środowisko zmienia się podczas każdej regeneracji, reduktor może wytwarzać mniejszy stan dla innego problemu. Zachowaj manifest odtwarzania z tymi wejściami i obserwowanym rezultatem. Wyjście nie jest tylko mniejszym plikiem; jest to przypadek regresji, który ktoś inny może wykonać.
Generowane oprawy regresji powinny wejść w tę samą ścieżkę recenzji, co ręcznie autorskie. Daj każdej oprawie stabilną nazwę, krótkie wyjaśnienie awarii, niezmienny zachowuje, i oczekiwaną klasyfikację. Oprawa regresji jest cenna, ponieważ sprawia, że wcześniej zaskakujące granice rutynowe. Nie powinno stać się ukrytym źródłem danych gracza produkcji lub chwyt - wszystko dla niewyjaśnionych niepowodzeń.
Umieść próbę w CI nie powodując hałasu
Uruchom szybki, reprezentatywny podzbiór na każdej istotnej zmianie: aktualne krawędzie migracji, stany historyczne wysokiego ryzyka i mały zestaw determinujących mutacji. Uruchom pełny korpus na zaplanowanej pracy, release candidate lub zmiany, które dotykają serializacji, progresji, interpretacji katalogowej, synchronizacji chmur, lub Save- format kodu. Odłamek przez osprzęt rodziny lub krawędzi migracji zamiast wysyłania każdego testu przez jedną długą sekwencję.
Wyjście CI powinno być zwięzłe, ale inspectable. Zgłoś ID urządzenia, wersji startowej i docelowej, krawędzi migracji, niezmiennej warstwy, pierwszego niepoprawnego punktu kontrolnego, i ścieżki do zredagowanego artefaktu lub diff. Unikaj drukowania pełnej zawartości profilu w logach. Gdy awaria jest nowa, zachować minimalne informacje potrzebne do powielania go lokalnie; gdy jest to spodziewane, odnotować, że klasyfikacja tak wydanie nie po cichu normalizuje znane ryzyko.
Decyzja o wydaniu powinna określać, co oznacza dowód. Przekazywanie testów migracji wspiera ograniczone roszczenia: sprawdzone korpus i zadeklarowane ścieżki zachowały się zgodnie z oczekiwaniami w tym środowisku. Nie udowadniają one, że każdy gracz oszczędza, urządzenie lub usługa zewnętrzna będzie zachowywać się identycznie. Zespoły nadal potrzebują planów roll back, obsługi klienta-wsparcia i monitorowania, że poszanowanie prywatności.
Praktyczna lista kontrolna
- Zachować wersjonowany korpus historyczny z etykietami scenariuszy i klasyfikacjami prywatności.
- Kopiowanie wejść przed migracją i zachowanie hashów dla artefaktów źródłowych i wyjściowych.
- Narysuj obsługiwane krawędzie migracji, w tym politykę w wersji poślizgowej i wyraźne odrzucenie.
- Weryfikacja struktury, referencji, domeny i bezpieczeństwa po każdym punkcie kontrolnym.
- Round- trip migrował wyjście przez obecnego pisarza i czytelnika.
- Do testowania brakujących pól, duplikatów rekordów, zawartości na emeryturze i wartości granicznych należy stosować determinujące mutacje.
- Redukcja powtarzalnych awarii do zweryfikowanych elementów regresji z manifestami powtórzeń.
- Uruchom podzbiory skupione na ryzyku w sposób ciągły, a cały korpus przed zmianami wrażliwymi na działanie substancji.
- Zachowaj logi i artefakty zredagowane; nie zamieniaj CI w archiwum danych player-.
Często zadawane pytania
Czy potrzebujemy prawdziwego gracza, aby przetestować migrację?
Nie. Rzeczywiste kształty historyczne są przydatne, ale korpus może być syntetyczny lub starannie zredagowane. Ważne jest zachowanie trudnych kombinacji stanu: zawartość emerytów, długi postęp, przerywane przejścia, opcjonalne dane i wartości na znaczących granicach. Jeśli dane produkcyjne są wykorzystywane do odkrycia przypadku krawędzi, uzyskać bezpieczne mocowanie, które zachowuje tylko nieruchomości w trakcie testu.
Czy każda stara wersja powinna pozostać wspierana na zawsze?
Niekoniecznie. Wsparcie jest produktem i decyzją operacyjną. Ważne jest, aby granica była wyraźna: które wersje migrują, które wymagają wcześniejszej aktualizacji, które są odrzucone, i jak gracz jest informowany. Nieudokumentowana ścieżka przypadkowa jest najmniej bezpieczną opcją, ponieważ nie jest ona ani wiarygodnie wspierana, ani wyraźnie odrzucona.
Czy test serializera może zastąpić test rozgrywki?
Nie. Serializujące testy potwierdzają, że dane mogą być odczytywane i zapisywane zgodnie z deklarowanymi kształtami. Testy Gameplay i domeny potwierdzają, że uzyskany stan ma sens w obecnym przepisie. Solidna próba migracji wymaga zarówno, jak i przeglądu treści i referencji konfiguracyjnych, które wpływają na znaczenie zapisanych wartości.
Jaka jest tutaj rola Persistium?
Persistium jest rodziną produktów o wysokiej niezawodności. Wskazówki zawarte w tej nocie to praktyczne doradztwo inżynieryjne, a nie twierdzenie, że dostępny jest publiczny produkt Persistium lub że zdiagnozowano prawdziwe dane klientów. Jego kierunek ciągłości bada rodzaj wyraźnej migracji, powtórki, porównania i redukcji pracy opisane powyżej.
