O eliberare este o plasă, nu un număr de versiune
Jocuri și aplicații conectate rareori actualizează ca un obiect indivizibil. Un jucător poate deschide un client vechi în timp ce un serviciu s-a schimbat deja. Un catalog de conținut poate actualiza în fața clientului care înțelege un nou element. Un rollout de configurare poate ajunge într-o regiune înainte de alta. Un suport poate accepta atât forme de cerere vechi și noi pentru un timp, apoi retrage un adaptor. 42Depășiți relațiile cele mai susceptibile de a rupe în condiții reale de lansare.
Începeți prin numirea dimensiunilor versiunii separat. Cel puțin, înregistrați construi client, backend sau revizie de serviciu, versiunea de protocol, schema sau salva versiunea, versiunea catalog de conținut, versiunea de configurare, și starea de migrare. Unele produse au nevoie, de asemenea, versiunea activ-bundle, set caracteristică-flag, capacitatea de operare-sistem, cohorta de cont, sau regiune. Scopul nu este de a crea o foaie de calcul gigant pentru propria sa de dragul. Este de a dezvălui în cazul în care o componentă interpretează un alt element de ieșire.
Întrebarea utilă nu este „a trecut testele cel mai nou client?”, ci „ce combinații pot coexista, ce trebuie să facă fiecare combinație și ce combinații sunt interzise?”. O politică de compatibilitate transformă această întrebare într-un spațiu de testare delimitat. Ea precizează intervalele acceptate, adaptoarele de compatibilitate, mecanismele de dezactivare de urgență, refuzurile controlate și condițiile de lansare înainte ca un incident în producție să oblige echipa să ghicească.
Scrie constrângeri de compatibilitate în ambele direcții
Compatibilitatea este adesea asimetrică. Un nou suport poate accepta cereri de la un client vechi, în timp ce un backend vechi nu poate înțelege un client nou. Un client nou poate citi un vechi salva după migrare, în timp ce un client vechi nu trebuie să redeschidă versiunea migrată. Noul conținut poate fi inofensiv pentru clienții vechi atunci când este ascuns de un steag caracteristică, dar periculos atunci când un client vechi tratează un tip de element necunoscut ca un implicit valid.
Scrie fiecare constrângere ca o relație cu un comportament așteptat. De exemplu: client 5 se poate autentifica împotriva serviciului 7 prin protocol 2; client 4 pot citi catalogul 10 numai în cazul în care elementele de tip X sunt excluse; salvează schema 3 pot migra la 5 prin margini susținute; configurație 12 nu trebuie să permită o caracteristică pentru clienții de mai jos construi 6. Include o dispoziție pentru combinații nesusținute: bloc înainte de mutație, servi o reprezentare compatibilă, calea către o actualizare necesară, sau țineți schimbarea până când vechea cohortă se scurge.
Nu te baza doar pe comparaţia versiunilor. Un număr mai mare nu dovedeşte existenţa unei capacităţi, iar un număr mai vechi nu dovedeşte absenţa unei caracteristici. Utilizaţi negocierea capacităţilor sau metadatele explicite de compatibilitate acolo unde sunt practice. Metadatele în sine necesită teste; un pavilion lipsă nu ar trebui să însemne accidental că trebuie continuat.
Generează o matrice axată pe risc
Produsul complet cartezian poate fi enorm. Patru client construiește, trei servicii, patru versiuni de conținut, și cinci state de configurare creează deja combinații 240 înainte de platforma și starea de migrare sunt luate în considerare. Testarea fiecare tuple posibil poate fi mai lent decât ciclul de eliberare și încă pierde limita care contează. În schimb, genera o matrice axată pe risc de constrângeri și impactul de schimbare.
Include întotdeauna cea mai nouă cale compatibilă, cea mai veche cale încă susținută, și limitele de tranziție. Adăugați combinații care traversează un câmp de protocol modificat, margine de migrare, regula de interpretare a conținutului, calea de drepturi, sau steag caracteristică. Include cel puțin o cale în formă de rollback: un client sau serviciu revenind la o stare anterioară compatibilă după ce noul stat a observat date. Atunci când o schimbare este cu adevărat izolată, înregistrează de ce nu extinde matricea în loc să presupună în tăcere că nu o face.
Generarea de perechi poate ajuta la acoperirea interacțiunilor, dar nu ar trebui să înlocuiască judecata. Unele eșecuri necesită trei sau patru dimensiuni pentru a alinia: un client vechi, un nou catalog, o salvare migrată, și un steag de configurare ar putea fi în siguranță în fiecare pereche, dar invalid împreună. Adăugați teste de scenariu numite pentru aceste riscuri specifice produsului. Matricea ar trebui să fie reconsiderabilă de către persoanele care înțeleg caracteristicile, nu numai de către un generator de testare.
Testați clienții vechi și noi care trăiesc împreună
Coexistenţa este o condiţie normală de desfăşurare. Simulaţi un client vechi crearea sau modificarea stării în timp ce un client nou îl citeşte, apoi inversaţi comanda. Test reconectează, sesiuni concomitente, descărcări întrerupte de actualizare, şi un utilizator care reia pe un alt dispozitiv. Pentru fiecare cale, identifica care parte deţine o interpretare autoritară. Un client nu ar trebui să inventeze o nouă valoare de teren pe care serviciul o tratează ulterior ca fiind de încredere doar pentru că ambele au fost actualizate într-un singur test local.
Modificările protocolului merită adaptoare explicite. Atunci când un câmp este redenumit, tastat sau împărţit în mai multe valori, testarea vechii reprezentări, a noii reprezentări şi a oricărui strat de traducere. O traducere trebuie să păstreze semnificaţia documentată sau să respingă cererea înainte de o mutaţie nesigură. Un server returnând un implicit plauzibil dar greşit poate fi mai periculos decât o incompatibilitate clară, deoarece răspândeşte corupţia tăcută.
Compatibilitatea clientului include experienţa utilizatorului. Dacă o clădire veche nu poate continua în siguranţă, calea de actualizare trebuie să apară înaintea unei acţiuni de stat, nu după o tranzacţie eşuată. Dacă o caracteristică este ascunsă de vechile construcţii, confirmaţi că rămâne ascunsă în meniuri, link-uri adânci, puncte de intrare de tip împinge, şi sesiuni restaurate. O decizie corectă de backend se poate simţi încă ruptă dacă interfaţa prezintă o acţiune pe care clientul curent nu o poate completa.
Tratează conținutul și configurația ca dependențe executabile
Cataloagele de conținut și configurarea la distanță sunt adesea considerate date operaționale mai degrabă decât coduri. Într-un sistem live, acestea sunt dependențe executabile, deoarece ele schimbă ceea ce înseamnă identificatorii, care apar caracteristici, și care se aplică reguli. Testați un nou catalog de conținut cu clienții vechi și noi. Testați un cache de configurare vechi cu un nou serviciu. Testați un steag caracteristică care să permită o cale de cod înainte de a fi prezent conținutul necesar. Testați o rollback de conținut după ce unii jucători au dobândit referințe la noul record.
Utilizați contracte de conținut modificate. O înregistrare în catalog ar trebui să declare câmpurile și capacitățile necesare pentru a-l face sau executa. Un pachet de configurare ar trebui să identifice clientul sau gama de servicii se așteaptă. Dacă o înregistrare depinde de o capacitate indisponibilă, alege un comportament sigur: ascundeți-l, înlocuiți o rezervă documentată, amâna activarea, sau opri rollout. Nu utilizați un implicit generic care acordă accidental un element, ocolește o verificare a drepturilor, sau modifică progresia.
Pentru starea salvată, distingeți migrarea schema de migrare semantică. O schimbare schema poate adăuga un câmp cu un implicit. O schimbare semantică poate pensiona un element, împărți o căutare, sau modifica o regulă economie. Acesta din urmă are nevoie de domenii invariante și decizii de recuperare, nu numai un test de deserializator. Înregistrați care versiune a catalogului și configurația interpretat starea salvată, mai ales atunci când o reluare sau o investigație de sprijin are nevoie pentru a reproduce un rezultat.
Dovedi rollback înainte de eliberare are nevoie de ea
Rollback nu este pur și simplu implementarea unui cod mai vechi. Întrebați dacă un client vechi poate citi starea scrisă de noul client, dacă un serviciu vechi poate interpreta noi cereri, dacă înregistrările conținutului necesită un nou rander, și dacă o migrare a trecut o limită într-un sens unic. Unele schimbări sunt numai înainte. Acest lucru poate fi acceptabil atunci când este declarat, dar schimbă planul de lansare: utilizarea unei cohorte înscenate, o fereastră de compatibilitate, o politică de rezervă sau instantaneu, și o cale de sprijin în loc de a presupune o întoarcere instantanee.
Începeți pe vechiul set compatibil, avansați o componentă, faceți o schimbare de stat reprezentativă, apoi mutați o componentă selectată înapoi. Asertați starea așteptată: compatibilitatea continuă, siguranța numai pentru citire, refuzul controlat sau recuperarea planificată. Rezultatul ar trebui să numească ceea ce a fost executat și ceea ce a fost simulat. O revizuire nu ar trebui să confunde o diagramă de proiectare pentru o repetiție executabilă rollback.
Păstrați rezultatul deciziei scurt și concret. Recordul de lansare poate preciza: intervale de compatibilitate suportate, scenarii executate, riscuri neexecutate cunoscute, schimbări care sunt numai înainte, porți de lansare, și condiții de oprire. Ea nu ar trebui să pretindă siguranță universală, deoarece o matrice a trecut. Rezultatul onest este o limită de eliberare susținută de dovezi.
Shard dovezile în CI
Rulați un mic set de fum de compatibilitate pe fiecare schimbare care atinge contracte comune. Rulați cioburi extinse atunci când clientul, protocolul, salva, conținut, configurare, sau modificări de cod de lansare. Ciob de familie scenariu, mai degrabă decât prin combinații aleatorii: autentificare și restaurare sesiune, cumpărare și dreptul, migrare și salvate de stat, redarea conținutului, comportamentul de caracteristici-gated, și rollback. Acest lucru păstrează eșecuri semnificative și face vizibil costul unei noi dimensiuni.
Raportul CI ar trebui să păstreze tuplul sub test și clasificarea rezultatelor. Include construirea clientului, revizuirea serviciului, protocol, versiuni de conținut și configurare, fixare sau de scenariu ID, tipul de mediu, și prima regulă de compatibilitate eșuată. Evitați contul de dumping sau starea jucătorului. Atunci când un scenariu este simulat, etichetați-l. Atunci când un scenariu rulează împotriva unui adaptor executabil sau sandbox, etichetați că de asemenea. Calitatea probelor face parte din decizia de lansare.
Revizuiți aceste rapoarte cu proprietarii de presă înainte de a extinde o lansare; dovezi de compatibilitate este o intrare decizie, nu un tablou de bord decorativ.
Utilizați minimizarea eșecului atunci când un caz matrice rupe. Primul tuple care nu reușește poate conține versiuni sau steaguri inutile. Țineți încă mediul determinist, reduceți dimensiunile păstrând în același timp eșecul de compatibilitate, și stocați scenariul minim rezultat ca un caz de regresie. Acest lucru face matricea mai valoroasă în timp în loc de a deveni în mod constant o colecție zgomotoasă de accidente istorice.
Lista de verificare practică
- Nume client, serviciu, protocol, schema, conţinut, configuraţie, şi migraţie dimensiuni separat.
- Scrieţi relaţii susţinute, traduse şi interzise de compatibilitate cu comportamentul aşteptat.
- Include scenariile cu cel mai vechi suport, cele mai noi, de tranziție și în formă de rollback.
- Adăugați teste multidimensionale numite în cazul în care acoperirea pereche este insuficientă.
- Testați clienții vechi și noi crearea, citirea și reluarea statului peste aceeași limită de serviciu.
- Tratează catalogul și modificările de configurare ca dependențe de compatibilitate executabile.
- Declară migrații numai în avans și furnizează un plan de implementare sau de recuperare în etape.
- Înregistrați dacă dovezile sunt simulate, executabile local, în cutii de nisip sau verificate extern.
- Păstrați tuple minim de cădere ca un scenariu de regresie revizuite.
Întrebări frecvente
Este suficient de testare pereche pentru a elibera compatibilitatea?
Acoperirea perechilor este un mod util de a reduce o matrice mare, dar nu poate dovedi toate constrângerile multidimensionale. Utilizați-l pentru acoperire largă de interacțiune, apoi adăugați scenarii explicite pentru combinații cu risc ridicat, cum ar fi starea migrată plus un conținut nou plus un client vechi, sau o rollback după o poartă de configurare sa schimbat.
Când ar trebui să fie blocat un client vechi?
Blocați-l înainte de mutație atunci când nu poate interpreta în condiții de siguranță conținutul necesar, satisface un contract de protocol, sau citiți limita de stat curentă. O cerință de actualizare clară este mai sigură decât continuarea cu un implicit care schimbă sensul. Politica exactă este specifică produsului, dar condiția și comportamentul cu care se confruntă utilizatorul ar trebui testate împreună.
Poate un steag caracteristică rezolva compatibilitatea de la sine?
Nu. Un steag poate controla expunerea, dar nu poate face un protocol incompatibil, schema, sau înregistrare de conținut în condiții de siguranță. Testați steagurile state cached și actualizate, dependența sa de capacitățile clienților, și ce se întâmplă dacă se schimbă în timp ce o sesiune este activă.
Ce presupune acest lucru despre Persistium?
Persistium este o familie de produse de prima fiabilitate locală în dezvoltare. Acest articol descrie o abordare de testare-proiectare, nu o afirmație că un produs lansat generează automat fiecare matrice sau oferă managementul de lansare găzduit. Direcția de Continuitate explorează dovezi delimitate pentru tipurile de decizii de compatibilitate descrise aici.
