Uwolnienie to siatka, nie jeden numer wersji
Połączone gry i aplikacje rzadko aktualizują się jako jeden niepodzielny obiekt. Gracz może otworzyć starego klienta, podczas gdy usługa już się zmieniła. Katalog treści może zaktualizować przed klientem, który rozumie nowy element. Routing konfiguracji może dotrzeć do jednego regionu przed innym. Backend może zaakceptować zarówno stare jak i nowe kształty prośby na chwilę, a następnie przejść na emeryturę adaptera. Traktując to wszystko jako "wersja 42" ukrywa relacje najbardziej prawdopodobne pęknięcia w rzeczywistych warunkach toczenia.
Rozpocząć od nazewnictwa wymiarów wersji osobno. Na co najmniej nagrywać tworzenie klienta, korektę obsługi lub usługi, wersję protokołu, schemat lub wersję zapisu, wersję katalogu treści, wersję konfiguracyjną i stan migracji. Niektóre produkty również potrzebują wersji asset- bull, zestaw feature- flag, funkcje operacyjne-systemowe, kohortę kont lub region. Celem nie jest stworzenie gigantycznego arkusza kalkulacyjnego dla własnego dobra.
Przydatne pytanie to nie "czy najnowszy klient przeszedł?" To jest "które kombinacje mogą współistnieć, co musi każda kombinacja zrobić, a które kombinacje są zabronione?" Polityka kompatybilności zamienia to pytanie w ograniczoną przestrzeń testową. Nazwy akceptowane zakresy, tłumaczy, wyłączników kill, pełne gracji odmowne, i rollout bramy przed incydentem produkcji zmusza zespół do odgadnięcia.
Zapisuj ograniczenia zgodności w obu kierunkach
Kompatybilność jest często asymetryczna. Nowe backend może akceptować prośby starego klienta, podczas gdy stare backend nie może zrozumieć nowego klienta. Nowy klient może odczytać stary zapis po migracji, podczas gdy stary klient nie może ponownie otworzyć migrowanej wersji. Nowa zawartość może być nieszkodliwa dla starych klientów, gdy jest ukryta przez flagę funkcji, ale niebezpieczna, gdy stary klient traktuje nieznany typ elementu jako ważny domyślny.
Zapisz każde ograniczenie jako związek z oczekiwanym zachowaniem. Na przykład: klient 5 może poświadczyć autentyczność przed doręczeniem 7 poprzez protokół 2; klient 4 może czytać katalog 10 tylko w przypadku gdy pozycje typu X są wyłączone; zapisać schemat 3 może migrować do 5 przez obsługiwane krawędzie; konfiguracja 12 nie może umożliwiać tworzenia funkcji dla klientów poniżej 6. Włączyć dyspozycję dla nieobsługiwanych kombinacji: blokować przed mutacją, służyć kompatybilnej reprezentacji, trasy do wymaganej aktualizacji, lub trzymać zmianę aż do starych kohort dreny.
Nie polegaj tylko na porównaniu wersji. Wyższa liczba nie udowadnia istnienia możliwości, a starsza liczba nie udowadnia nieobecności danej funkcji. Używaj negocjowania zdolności lub wyraźnych metadanych kompatybilności tam, gdzie jest to możliwe. Metadane same w sobie wymagają testów; brakująca flaga nie powinna przypadkiem oznaczać "bezpiecznego działania".
Generuj macierz skupioną na ryzyku
Cały produkt kartezjański może być ogromny. Cztery konstrukcje klientów, trzy usługi, cztery wersje treści i pięć stanów konfiguracyjnych tworzą już kombinacje 240 przed rozważeniem platformy i stanu migracji. Testowanie każdej możliwej krotki może być wolniejsze niż cykl uwalniania i nadal brakuje granicy, która ma znaczenie. Zamiast tego, generować skupioną na ryzyku matrycę z ograniczeń i wpływu zmiany.
Zawsze zawierają najnowszą ścieżkę kompatybilną, najstarszą ścieżkę obsługiwaną przez Stilla oraz granice przejściowe. Dodaj kombinacje, które przekraczają zmienione pole protokołu, granicę migracji, regułę interpretacji treści, ścieżkę uprawnień lub flagę funkcji. Wprowadź co najmniej jedną ścieżkę w kształcie rollbacka: klienta lub usługę powracającą do poprzedniego stanu kompatybilnego po tym, jak nowy stan zaobserwował dane. Gdy zmiana jest naprawdę odizolowana, zapisz dlaczego nie rozszerza matrycy zamiast cichego zakładania, że nie.
Pairwise generation może pomóc pokryć interakcje, ale nie powinno zastępować osądu. Niektóre niepowodzenia wymagają trzech lub czterech wymiarów, aby wyrównać: stary klient, nowy katalog, migrowane zapisać, i flaga konfiguracji może być bezpieczne w każdej parze jeszcze niepoprawny razem. Dodaj nazwane testy scenariuszy dla tych produktów specyficznych zagrożeń. Matryca powinna być przeglądana przez ludzi, którzy rozumieją cechy, nie tylko przez generator testów.
Test starych i nowych klientów mieszkających razem
Współistnienie jest normalnym warunkiem uruchomienia. Symulować stary klient tworzenie lub modyfikowanie stanu, podczas gdy nowy klient czyta go, a następnie odwrócić zamówienie. Test ponownie łączy, równoległe sesje, przerwane aktualizacje pobrań, a użytkownik, który wznawia na innym urządzeniu. Dla każdej ścieżki, określić, która strona posiada autorytatywną interpretację. Klient nie powinien wymyślać nowej wartości pola, że usługa później traktuje jako zaufany tylko dlatego, że obie zostały zaktualizowane w jednej lokalnej pracy testowej.
Zmiany protokołu zasługują na jednoznaczne adaptery. Po zmianie nazwy pola, rozszerzeniu typu lub podzieleniu się na wiele wartości, przetestować stare przedstawienie, nowe przedstawienie i każdej warstwy tłumaczenia. Tłumaczenie musi zachować udokumentowane znaczenie lub odrzucić wniosek przed niebezpieczną mutacją. Serwer zwracający prawdopodobną, ale błędną wartość domyślną może być bardziej niebezpieczne niż wyraźna niezgodność, ponieważ rozprzestrzenia cichą korupcję.
Kompatybilność klienta obejmuje doświadczenie użytkownika. Jeśli stary build nie może być bezpiecznie kontynuowany, ścieżka aktualizacji powinna pojawić się przed akcją stanu, a nie po nieudanej transakcji. Jeśli funkcja jest ukryta przed starymi buildings, potwierdzić, że pozostaje ukryta w menu, głębokie linki, push- podobne punkty wejścia i przywrócone sesje. Prawidłowa decyzja backend może nadal czuć się zepsuta, jeśli interfejs przedstawia działanie, którego obecny klient nie może zakończyć.
Traktuj zawartość i konfigurację jako zależności wykonywalne
Katalogi treści i konfiguracje zdalne są często uważane za dane operacyjne, a nie kod. W systemie live, są one wykonywalne zależności, ponieważ zmieniają co oznaczają identyfikatory, które funkcje się pojawiają i jakie zasady mają zastosowanie. Przetestować nowy katalog treści ze starymi i nowymi klientami. Przetestować stalowe bufory konfiguracyjne z nową usługą. Przetestować flagę funkcji umożliwiającą ścieżkę kodu zanim pojawi się wymagana zawartość. Przetestować rollback treści po nabyciu przez niektórych graczy odniesienia do nowego rekordu.
Użyj skonfigurowanych kontraktów na zawartość. Wpis w katalogu powinien zadeklarować pola i możliwości wymagane do renderowania lub wykonania go. Pakiet konfiguracyjny powinien zidentyfikować klienta lub zakres usług, którego się spodziewa. Jeśli rekord zależy od niedostępności, wybierz bezpieczne zachowanie: ukryj go, zastąp udokumentowane awaryjne, opóźnij aktywację lub wstrzymaj uruchomienie. Nie używaj ogólnego domyślnego, który przypadkowo przyznaje element, pomija kontrolę uprawnień lub zmienia progresję.
Dla zapisanego stanu, odróżnić migrację schematów od migracji semantycznej. Zmiana schematu może dodać pole z domyślną. Zmiana semantyczna może wycofać element, podzielić zadanie, lub zmienić regułę gospodarki. Ten ostatni potrzebuje invariants domeny i decyzji o odzyskaniu, nie tylko test deserializer. Zapis, która wersja katalogu i konfiguracji interpretuje zapisany stan, zwłaszcza, gdy powtórka lub badanie wsparcia musi odtworzyć wynik.
Udowodnij, że rollback przed wydaniem go potrzebuje
Rollback nie jest po prostu rozmieszczanie starszego kodu. Zapytaj, czy stary klient może odczytać stan napisany przez nowego klienta, czy stara usługa może interpretować nowe żądania, czy zapisy treści wymagają nowego renderera, i czy migracja przekroczyła granicę jednokierunkową. Niektóre zmiany są przenoszone - tylko. To może być akceptowalne, gdy deklarowane, ale zmienia plan wydania: użyj ustawionej kohorty, okna kompatybilności, kopii zapasowej lub polityki migawki, a ścieżka wsparcia zamiast zakładania natychmiastowego zwrotu.
Rozpocząć na starym zestawie kompatybilnym, awansować jeden składnik, dokonać reprezentatywnej zmiany stanu, a następnie przenieść wybrany składnik z powrotem. Skorzystaj z oczekiwanego stanu: ciągła kompatybilność, bezpieczeństwo tylko read-, kontrolowana odmowa lub planowana regeneracja. Wynik powinien zawierać nazwę tego, co zostało wykonane i co było symulowane. Przegląd nigdy nie powinien pomylić diagramu projektu dla próby wykonania rollback.
Zachować wynik decyzji krótki i betonowy. Rekord wydania może określać: obsługiwane zakresy kompatybilności, scenariusze wykonane, znane niewykonane ryzyka, zmiany, które są forward- tylko, Rolout bram, i warunki do zatrzymania. Nie powinien ubiegać się o uniwersalne bezpieczeństwo, ponieważ matryca przeszła. Szczery wynik jest dowodowo backed granica wydania.
Rozdarcie dowodów w CI
Uruchom mały dym kompatybilności ustawiony na każdej zmianie, która dotyka wspólnych kontraktów. Uruchom rozszerzone odłamki, gdy klient, protokół, zapisać, zawartość, konfiguracja, lub zmiany kodu rollout. Odłamek według rodziny scenariuszy, a nie losowe kombinacje: uwierzytelnienie i przywracanie sesji, zakup i uprawnienia, migracja i zapisany stan, renderowanie treści, zachowanie feature- fatched i rollback. To utrzymuje niepowodzenia znaczące i sprawia, że koszt nowego wymiaru widoczne.
Raport CI powinien zachować kolejkę testową i klasyfikację wyników. Należy uwzględnić budowę klienta, przegląd usług, protokół, treść i wersje konfiguracji, identyfikator urządzenia lub scenariusza, typ środowiska oraz pierwszą nieudaną regułę kompatybilności. Unikaj wyrzucania konta lub stanu gracza. Kiedy scenariusz jest symulowany, oznacz go. Gdy scenariusz działa w stosunku do adaptera wykonywalnego lub piaskownicy, etykieta, że też. Jakość dowodów jest częścią decyzji wydania.
Przegląd tych raportów z właścicielami wydania przed poszerzeniem wprowadzania; dowody zgodności jest wkład decyzji, a nie dekoracyjna deska rozdzielcza.
Użyj minimalizacji awarii, gdy awaria przypadku macierzy pęka. Pierwsza awaria krotka może zawierać niepotrzebne wersje lub flagi. Przytrzymaj środowisko deterministyczne nadal, zmniejszyć wymiary przy jednoczesnym zachowaniu awarii kompatybilności, i przechowywać wynikający z tego minimalny scenariusz jako przypadku regresji. To sprawia, że matryca bardziej cenne z czasem zamiast stale staje się hałaśliwym zbiorem historycznych wypadków.
Praktyczna lista kontrolna
- Wymień oddzielnie wymiary klienta, usługi, protokołu, schematów, treści, konfiguracji i migracji.
- Napisz wspierany, przetłumaczony i zakazany związek kompatybilności z oczekiwanym zachowaniem.
- Włączaj wcześniej obsługiwane scenariusze, newest- obsługiwane, przejściowe i rollback kształtowane.
- Dodać nazwane wielowymiarowe testy, w których zakres pairwise jest niewystarczający.
- Sprawdzić starych i nowych klientów tworzenie, czytanie i wznowienie stanu przez tę samą granicę usług.
- Traktuj katalog i zmiany konfiguracji jako zależności od kompatybilności wykonywalnej.
- Declare forward - tylko migracje i dostarczyć plan etapowego uruchamiania lub naprawy.
- Zapisuj, czy dowody są symulowane, wykonywalne lokalnie, piaskowane lub weryfikowane zewnętrznie.
- Zachować minimalny ubytek kropek jako zrewidowany scenariusz regresji.
Często zadawane pytania
Czy testy pairwise są wystarczające, aby zapewnić kompatybilność wydawnictwa?
Pairwise pokrycie jest użytecznym sposobem na zmniejszenie dużej matrycy, ale nie może udowodnić wszystkich wielowymiarowych ograniczeń. Użyj go do szerokiego zakresu interakcji, a następnie dodać wyraźne scenariusze dla kombinacji wysokiego ryzyka, takich jak migrowane stan plus nowa zawartość plus stary klient, lub rollback po zmianie bramy konfiguracji.
Kiedy należy zablokować starego klienta?
Blokowanie go przed mutacją, gdy nie może bezpiecznie interpretować wymaganej treści, spełnić protokół umowy, lub przeczytać bieżącą granicę stanu. Jasny wymóg aktualizacji jest bezpieczniejszy niż kontynuowanie z domyślnym, że zmiany znaczenie. Dokładna polityka jest product- specyficzne, ale stan i zachowanie użytkownika powinno być testowane razem.
Czy flaga funkcji może samodzielnie rozwiązać kwestię kompatybilności?
Nie. Flaga może kontrolować ekspozycję, ale nie może sprawić, że protokół, schematy lub zapis treści będą bezpieczne. Sprawdź buforowane i zaktualizowane stany flagi, jej zależność od możliwości klienta, a co się stanie, jeśli zmieni się podczas sesji jest aktywny.
Co to oznacza w związku z Persistium?
Persistium to rodzina produktów o wysokiej niezawodności. Ten artykuł opisuje podejście testowe, a nie twierdzenie, że dany produkt automatycznie generuje każdą matrycę lub zapewnia zarządzanie wydaniem hostingowym. Jego kierunek ciągłości to badanie ograniczonych dowodów na rodzaje decyzji zgodności opisanych tutaj.
