Uvolnění je síťka, ne jedno číslo verze
Spojení her a aplikací málokdy aktualizuje jako jeden nedělitelný objekt. Hráč může otevřít starého klienta, zatímco služba se již změnila. Katalog obsahu může aktualizovat před klientem, který rozumí nové položce. Konfigurace rollout může dosáhnout jednoho regionu před druhým. Backend může akceptovat jak staré a nové tvary žádosti na chvíli, pak odebrat adaptér. Zachází se to jako "verze 42" skrývá vztahy s největší pravděpodobností zlomit za reálných podmínek rolloutu.
Začněte pojmenováním dimenzí verze zvlášť. Minimálně zaznamenávejte build, backend nebo servisní revizi, verzi protokolu, schema nebo uložit verzi, verzi obsahu, konfigurační verzi a stav migrace. Některé produkty také potřebují asset- ball verzi, konfigurační-flag set, operating- system schopnost, účet kohorta, nebo region. Cílem není vytvořit obří tabulku pro vlastní účely. Je odhalit, kde jedna složka interpretuje výstup jiné komponenty.
Užitečná otázka není "prošel nejnovější klient?" To je ", které kombinace mohou koexistovat, co musí každá kombinace dělat, a které kombinace jsou zakázány?" Zásada kompatibility změní tuto otázku na ohraničený zkušební prostor. Pojmenuje přijaté rozsahy, překladatelé, zabít spínače, elegantní odmítnutí, a rollout brány před výrobní incident nutí tým hádat.
Napsat omezení slučitelnosti v obou směrech
Kompatibilita je často asymetrická. Nový backend může přijímat žádosti od starého klienta, zatímco starý backend nemůže pochopit nového klienta. Nový klient může číst staré uložení po migraci, zatímco starý klient nesmí znovu otevřít migrující verzi. Nový obsah může být neškodný pro staré klienty, když je skryt příznak funkce, ale nebezpečný, když starý klient zachází s neznámým typem položky jako s platným defaultem.
Napište každé omezení jako vztah s očekávaným chováním. Například: klient 5 může být ověřen proti doručení 7 prostřednictvím protokolu 2; klient 4 může číst katalog 10 pouze v případě, že položky typu X jsou vyloučeny; uložit schéma 3 může přejít na 5 přes podporované hrany; konfigurace 12 nesmí umožnit funkci pro klienty pod build 6. Zahrnout dispozice pro nepodporované kombinace: blokovat před mutací, sloužit kompatibilní reprezentaci, cesta k požadované aktualizaci, nebo držet změnu, dokud starý kohorta kanalizace.
Nespoléhejte se pouze na porovnání verzí. Vyšší počet neprokazuje schopnost existuje, a starší číslo neprokazuje funkci chybí. Použijte možnost vyjednávání nebo explicitní metadata kompatibility tam, kde je to praktické. Metadata sama potřebuje testy; chybějící vlajka by neměla náhodou znamenat "bezpečný postup".
Vygenerovat matici zaměřenou na riziko
Kompletní kartézský produkt může být obrovský. Čtyři klientské budovy, tři služby, čtyři verze obsahu, a pět konfiguračních stavů již vytvořit 240 kombinace před platforma a migrace stavu jsou považovány za. Testování každé možné tuple může být pomalejší než uvolnění cyklu a stále chybí hranice, na které záleží. Místo toho, generovat rizikově zaměřený matice z omezení a změnit dopad.
Vždy patří nejnovější kompatibilní cesta, nejstarší still- podporovaná cesta, a přechodové hranice. Přidat kombinace, které překračují změněné pole protokolu, migrační hrana, interpretační pravidlo obsahu, cesta oprávnění, nebo funkce vlajky. Zahrnout alespoň jednu cestu rollback- tvarované: klient nebo služba se vrací do předchozího kompatibilního stavu po novém stavu zaznamenal data. Když změna je skutečně izolován, zaznamenat, proč se nerozšiřuje matice místo tiše předpokládat, že ne.
Generace párů může pomoci pokrýt interakce, ale to by nemělo nahradit úsudek. Některé poruchy vyžadují tři nebo čtyři rozměry sladit: starý klient, nový katalog, migrující uložit, a konfigurační vlajka by mohla být bezpečná v každém páru ještě neplatné společně. Přidat pojmenované Scénáře testy pro tyto produkt- specifické rizika. Matrice by měla být přezkoumána lidmi, kteří chápou vlastnosti, a to nejen testovacím generátorem.
Otestujte staré a nové klienty žijící společně
Koexistence je normální stav rolloutu. Simulovat starý klient vytvářet nebo měnit stav, zatímco nový klient ji čte, pak zvrátit pořadí. Test se znovu připojí, souběžné relace, přerušené aktualizace stahování, a uživatel, který pokračuje na jiném zařízení. Pro každou cestu, identifikovat, která strana vlastní autoritativní interpretaci. Klient by neměl vynalézt novou hodnotu pole, které služba později zachází jako důvěryhodné jen proto, že oba byly aktualizovány v jednom místním testu.
Změny protokolu si zaslouží explicitní adaptéry. Pokud je pole přejmenováno, rozšířeno nebo rozděleno na více hodnot, otestujte staré reprezentace, nové reprezentace a jakoukoli překladatelskou vrstvu. Překlady musí zachovat dokumentovaný význam nebo odmítnout požadavek před nebezpečnou mutací. Server vracející věrohodný, ale nesprávný výchozí stav může být nebezpečnější než jasná nekompatibilita, protože šíří tichou korupci.
Kompatibilita s klientem zahrnuje uživatelskou zkušenost. Pokud stará budova nemůže bezpečně pokračovat, měla by se cesta aktualizace objevit před stálou akcí, ne po neúspěšné transakci. Pokud je funkce skryta před starými budovami, potvrďte, že je skryta v menu, hlubokých odkazech, vtlačeních jako vstupní body, a obnovených sezeních. Správné rozhodnutí o zálohování se může stále cítit poškozené, pokud rozhraní představuje akci, kterou současný klient nemůže dokončit.
Zacházet s obsahem a konfigurací jako se spustitelnými závislostmi
Obsah katalogů a vzdálené konfigurace jsou často považovány za provozní data spíše než kód. V živém systému, jsou spustitelné závislostí, protože mění, co identifikátory znamenají, které funkce se objeví, a která pravidla platí. Otestujte nový katalog obsahu se starými a novými klienty. Otestujte stagální konfigurační cache s novou službou. Otestujte vlajku funkce umožňující cestu kódu před požadovaným obsahem je přítomen. Otestujte obsah rollback poté, co někteří hráči získali odkazy na nový záznam.
Použijte kontrakty s obsahem s verzí. Zápis z katalogu by měl uvádět pole a schopnosti potřebné k jeho provedení nebo provedení. Konfigurační balíček by měl identifikovat klienta nebo rozsah služeb, které očekává. Pokud záznam závisí na nedostupnosti, zvolte bezpečné chování: skryjte ho, nahraďte zdokumentovaný záloha, odkládací aktivaci, nebo zastavit rollout. Nepoužívejte obecný default, který náhodně udělí položku, obejde kontrolu nároků nebo změní progresi.
Pro uložený stav, rozlišovat schéma migrace od sémantické migrace. Schéma změna může přidat pole s výchozí. Semantická změna může odejít položku, rozdělit pátrání, nebo změnit pravidlo ekonomiky. Ten potřebuje domény invariants a rozhodnutí o navrácení, nejen deserializér test. Zaznamenejte, která verze katalogu a konfigurace interpretuje uložený stát, zejména pokud replay nebo podpora šetření potřebuje reprodukovat výsledek.
Dokaž návrat, než to vydání potřebuje
Rollback není jen nasazení starší kód. Zeptejte se, zda starý klient může číst stav napsaný novým klientem, zda stará služba může interpretovat nové požadavky, zda obsah záznamy vyžadují nového nositele, a zda migrace překročila jednosměrnou hranici. Některé změny jsou forward- only. To může být přijatelné, když je deklarován, ale to změní plán uvolnění: použít modelované cohort, kompatibilní okno, zálohování nebo snímek politiky, a podpůrná cesta namísto převzetí okamžitého návratu.
Test schopnost převrácení jako scénář. Začněte na staré kompatibilní soubor, dopředu jednu složku, provést reprezentativní změnu stavu, pak přesunout vybrané komponenty zpět. Assert očekávaný stav: pokračující kompatibilita, read- pouze bezpečnost, kontrolované odmítnutí, nebo plánované zotavení. Výsledek by měl pojmenovat, co bylo provedeno a co bylo simulováno. Recenze by nikdy omyl design diagram pro zkoušku spustitelného převrácení.
Udržet rozhodovací výstup krátký a konkrétní. Záznamy o uvolnění může uvést: podporované rozsahy kompatibility, provedených scénářů, známá neprovedená rizika, změny, které jsou pouze forward- pouze, rollout brány, a podmínky pro zastavení. Nemělo by nárok na univerzální bezpečnost, protože matice prošel. Čestný výsledek je důkaz - podporované hranice uvolnění.
Rozdělte důkazy v CI.
Spustit malý kompatibilitu kouř nastavit na každé změně, která se dotkne sdílených smluv. Spustit rozšířený střepy, když klient, protokol, uložit, obsah, konfigurace, nebo rollout kód změny. Shard podle scénáře rodina spíše než náhodnými kombinacemi: autentizace a obnovení relace, nákup a nárok, migrace a uložený stav, vykreslování obsahu, filmuregled chování, a rollback. To udržuje selhání smysluplné a činí náklady na nové dimenze viditelné.
Zpráva CI by měla zachovat tuple pod testem a klasifikace výsledku. Zahrnout budovat klienta, revize služeb, protokol, obsah a konfigurační verze, fiktura nebo ID scénáře, typ prostředí, a první neúspěšné pravidlo kompatibility. Vyhněte se Dumping účet nebo stav hráče. Když je scénář simulovaný, označte to. Když scénář běží proti spustitelného adaptéru nebo pískoviště, štítek, že také. Důkazy kvalita je součástí rozhodnutí o uvolnění.
Prohlédněte si tyto zprávy s majiteli vydání před rozšířením rollout; kompatibilita důkazy je vstup rozhodnutí, ne dekorativní palubní deska.
Používejte minimalizaci selhání, když se případ matice rozbije. První případ selhání tuple může obsahovat zbytečné verze nebo vlajky. Držte deterministické prostředí stále, snížit rozměry při zachování selhání kompatibility, a uložit výsledný minimální scénář jako regresní případ. To dělá matrici cennější v čase, místo aby se neustále stává hlučné sbírky historických nehod.
Praktický kontrolní seznam
- Jmenujte klienta, službu, protokol, schéma, obsah, konfiguraci a migrační rozměry zvlášť.
- Piš podporované, přeložené a zakázané vztahy s očekávaným chováním.
- Zahrnout scénáře podporované oldest-, nové- podporované, přechodové a rollback- tvarované.
- Přidat pojmenované multidimenzionální testy, kde pairwise pokrytí je nedostatečné.
- Otestujte staré a nové klienty vytvářet, číst a obnovovat stav přes stejnou hranici služeb.
- Léčit katalog a konfigurační změny jako spustitelné závislosti na kompatibilitě.
- Declare forward-pouze migrace a poskytnout inscenovaný roll out nebo plán obnovy.
- Zaznamenejte, zda je důkaz simulován, spustitelný lokálně, pískovaný nebo externě ověřený.
- Zachovat minimální selhávající tuple jako přezkoumaný regresní scénář.
Často kladené otázky
Je párové testování dostatečné pro kompatibilitu s uvolňováním?
Pairwise pokrytí je užitečný způsob, jak snížit velkou matici, ale to nemůže prokázat všechny multidimenzionální omezení. Použijte ji pro široké pokrytí interakcí, pak přidat explicitní scénáře pro vysoce rizikové kombinace, jako je migrující stav plus nový obsah plus starý klient, nebo rollback po konfigurační brána změnila.
Kdy by měl být starý klient zablokován?
Blokovat před mutací, když to nemůže bezpečně interpretovat požadovaný obsah, splňovat protokol smlouvu, nebo číst aktuální státní hranice. Jasná aktualizace požadavek je bezpečnější, než pokračovat s výchozí, která mění význam. Přesná politika je produkt- specific, ale stav a uživatelsky-čelí chování by měly být testovány společně.
Může vlajka funkce vyřešit kompatibilitu sama o sobě?
Ne. Vlajka může kontrolovat expozici, ale nemůže učinit neslučitelný protokol, schéma, nebo obsah záznam bezpečné. Otestujte vlajka je cached a aktualizované stavy, jeho závislost na klientských schopností, a co se stane, pokud se změní, zatímco relace je aktivní.
Co to znamená o Persistium?
Persistium je in- development local- first responsibility product family. Tento článek popisuje test- design přístup, ne tvrzení, že uvolněný produkt automaticky generuje každou matici nebo poskytuje hostované řízení uvolnění. Jeho nepřetržitý směr je zkoumání ohraničených důkazů pro druhy rozhodnutí o kompatibilitě popsané zde.
