Vapautus on verkko, ei yksi versionumero
Yhdistetyt pelit ja sovellukset voidaan harvoin päivittää yhtenä jakamattomana objektina. Pelaaja voi avata vanhan asiakkaan, kun palvelu on jo muuttunut. Sisältöluettelo voi päivittää ennen asiakasta, joka ymmärtää uuden kohteen. Asennuksen käyttöönotto voi saavuttaa alueen ennen toista. Backend voi hyväksyä sekä vanhoja että uusia pyyntömuotoja joksikin aikaa, sitten vetäytyä adapterista. Tämän kaiken käsittely 42.X.
Aloita nimeämällä versiomitat erikseen. Vähintään, tallentaa asiakas rakentaa, backend tai service revision, protokollaversio, skeema tai tallentaa versio, sisältöluettelo versio, kokoonpano versio, ja migraatio tila. Jotkut tuotteet tarvitsevat myös varallisuuden bundle versio, ominaisuus-lippu asettaa, käyttö-järjestelmä valmiudet, tili kohortti, tai alue. Tavoitteena ei luoda jättiläinen laskentataulukko sen omaan tarkoitukseen. Se on paljastaa, jos yksi komponentti tulkitsee toisen komponentin.
Hyödyllinen kysymys ei ole ...eikö uusin asiakaspassi?..Se on ...mikä yhdistelmät voivat olla rinnakkain, mitä kukin yhdistelmä voi tehdä, ja mitkä yhdistelmät ovat kiellettyjä?... Yhteensopivuuspolitiikka muuttaa kysymyksen rajoitetuksi testitilaksi. Se nimeää hyväksytyt vaihteluvälit, kääntäjät, tappokytkimet, armolliset kieltäytymiset ja asennusportit ennen tuotantotapahtumaa pakottaa tiimin arvaamaan.
Kirjoita yhteensopivuusrajoitukset molempiin suuntiin
Yhteensopivuus on usein epäsymmetristä. Uusi backend voi hyväksyä pyyntöjä vanhalta asiakkaalta, kun taas vanha backend ei voi ymmärtää uutta asiakasta. Uusi asiakas voi lukea vanhan tallennuksen siirtymisen jälkeen, kun taas vanha asiakas ei saa avata muutettua versiota uudelleen. Uusi sisältö voi olla vaaratonta vanhoille asiakkaille, kun ominaisuusmerkki piilottaa, mutta vaarallinen, kun vanha asiakas kohtelee tuntematon kohde tyyppi voimassa oletuksena.
Esimerkiksi: asiakas 5 voi todentaa palvelun 7 kautta protokolla 2; asiakas 4 voi lukea luettelon 10 vain silloin, kun tyypin X kohteita ei oteta huomioon; tallenna schema 3 voi siirtyä 5 kautta tuettujen reunojen; konfiguraatio 12 ei saa mahdollistaa ominaisuutta asiakkaille alle rakentaa 6X. Mukaan lukien dispositiot tuettomille yhdistelmille: estää ennen mutaatiota, palvella yhteensopivaa edustusta, reittiä vaadittuun päivitykseen, tai säilyttää muutosta kunnes vanhat kohortit valuvat.
Älä luota pelkästään versiovertailuun. Suurempi määrä ei todista, että kyvykkyyttä on olemassa, ja vanhempi luku ei todista, että ominaisuutta ei ole. Käytä valmiusneuvotteluja tai selkeää yhteensopivuusmetadataa silloin, kun se on käytännöllistä. Metadata itsessään tarvitsee testejä; puuttuva lippu ei saa vahingossa tarkoittaa "turvallista jatkaa."
Luo riskipainotteinen matriisi
Koko kartesialainen tuote voi olla valtava. Neljä asiakas rakentaa, kolme palvelua, neljä sisältöversiota, ja viisi konfiguraatiotilaa jo luoda 240 yhdistelmiä ennen alustan ja migraatiotila harkitaan. Testaaminen jokainen mahdollinen tuple voi olla hitaampi kuin julkaisusykli ja silti ohittaa rajan, että merkitystä. Sen sijaan, luoda riskipainotteinen matriisi rajoitteista ja muutos vaikutuksia.
Mukaan tulee aina uusin yhteensopiva polku, vanhin edelleen tuettu polku ja siirtymärajat. Lisää yhdistelmiä, jotka ylittävät muuttuneen protokollakentän, siirtymäreunan, sisällön tulkintasäännön, oikeuspolun tai ominaisuuslipun. Sisällytä ainakin yksi rollback-muotoinen polku: asiakas tai palvelu, joka palaa aiempaan yhteensopivaan tilaan sen jälkeen, kun uusi tila on havainnut datan. Kun muutos on todella eristetty, kirjaa, miksi se ei laajenna matriisia sen sijaan, että olettaisi äänetttömästi, että se ei.
Parillinen sukupolvi voi auttaa peittämään vuorovaikutusta, mutta sen ei pitäisi korvata harkintaa. Jotkut viat vaativat kolme tai neljä ulottuvuutta yhdenmukaistaa: vanha asiakas, uusi luettelo, migrated tallenna, ja kokoonpano lippu voisi olla turvallinen jokaisessa parissa vielä virheellinen yhdessä. Lisää nimetty skenaario testejä näitä tuotekohtaisia riskejä. Matriksi pitäisi tarkistaa ihmiset, jotka ymmärtävät ominaisuuksia, ei vain testigeneraattori.
Kokeile vanhoja ja uusia asiakkaita, jotka asuvat yhdessä
Rinnakkaiskäyttö on normaali aloitustila. Simuloi vanha asiakas luoda tai muuttaa tilaa kun uusi asiakas lukee sen, sitten peruuttaa tilauksen. Test reconnect, samanaikaisia istuntoja, keskeytynyt päivitys lataukset, ja käyttäjä, joka jatkaa toisella laitteella. Kullekin polulle, tunnistaa kumpi puoli omistaa arvovaltaisen tulkinnan. Asiakkaan ei pitäisi keksiä uutta kenttäarvoa, että palvelu myöhemmin kohtelee luotettavaksi vain koska molemmat päivitettiin yhdessä paikallisessa testiajossa.
Protokollamuutokset ansaitsevat selvät adapterit. Kun kenttä on nimetty uudelleen, tyyppi laajennettu tai jaettu useaan arvoon, testaa vanha esitys, uusi esitys ja käännöskerros. Käännöksen on säilytettävä dokumentoitu merkitys tai hylättävä pyyntö ennen vaarallista mutaatiota. Palvelin, joka palauttaa uskottavan mutta väärän oletuksen, voi olla vaarallisempi kuin selvä yhteensopimattomuus, koska se levittää hiljaista korruptiota.
Asiakasyhteensopivuus sisältää käyttäjäkokemuksen. Jos vanha rakennus ei voi turvallisesti jatkua, päivityspolun pitäisi näkyä ennen tilaisempaa toimintaa, ei epäonnistuneen tapahtuman jälkeen. Jos ominaisuus on piilossa vanhoilta rakennuksilta, vahvista, että se pysyy piilossa valikoissa, syvissä linkeissä, työntämisen kaltaisissa syöttöpisteissä ja palautettuina istuntoihin. Oikea taustapäätös voi silti tuntua rikki, jos käyttöliittymä esittää toimen, jota nykyinen asiakas ei voi suorittaa.
Käsittele sisältöä ja konfiguraatiota suoritettavina riippuvuuksina
Sisältöluettelot ja etäasetukset ovat usein pikemminkin operatiivisia tietoja kuin koodia. Live-järjestelmässä ne ovat suorituskelpoisia riippuvuuksia, koska ne muuttavat sitä, mitä tunnisteet tarkoittavat, mitkä ominaisuudet näkyvät ja mitkä säännöt pätevät. Testaa uusi sisältöluettelo vanhoilla ja uusilla asiakkailla. Testaa vanhaa konfigurointivälimuistia uudella palvelulla. Testaa ominaisuuslippua, joka mahdollistaa koodipolun ennen vaaditun sisällön esittämistä. Testaa sisällön rollbackia, kun jotkut pelaajat ovat hankkineet viittaukset uuteen tietueeseen.
Käytä versioituja sisältösopimuksia. Luettelossa on ilmoitettava kentät ja ominaisuudet, joita tarvitaan sen renderointiin tai toteuttamiseen. Konfiguraatiopaketin tulisi tunnistaa odottamansa asiakas- tai palvelualueet. Jos tietue riippuu kyvyttömyydestä, valitse turvallinen käyttäytyminen: piilota se, korvaa dokumentoidun varauksen, lykkää aktivointia tai pysäytä käyttöönotto. Älä käytä yleistä oletusta, joka vahingossa myöntää kohteen, ohittaa oikeutustarkistuksen tai muuttaa etenemistä.
Semanttinen muutos voi poistaa kohteen, jakaa etsinnän tai muuttaa taloussääntöä. Jälkimmäinen tarvitsee verkkotunnuksen invariants ja palautumispäätökset, ei vain deserializer testi. Tallenna mikä versio luettelo ja konfiguraatio tulkittiin tallennettu tila, varsinkin kun uusinta- tai tukitutkimus on toistettava tulos.
Todista takaisin ennen julkaisu tarvitsee sitä
Rollback ei ole vain vanhemman koodin käyttöönotto. Kysy, voiko vanha asiakas lukea uuden asiakkaan kirjoittaman valtion, pystyykö vanha palvelu tulkitsemaan uusia pyyntöjä, vaatiiko sisältötiedostot uutta renderointia, ja onko muuttoliike ylittänyt yhdensuuntaisen rajan. Jotkut muutokset ovat vain eteenpäin. Tämä voidaan hyväksyä vain ilmoituksen yhteydessä, mutta se muuttaa julkaisusuunnitelmaa: käytä vaiheistettua kohorttia, yhteensopivuusikkunaa, varmuuskopiota tai kuvastoa sekä tukipolkua sen sijaan, että olettaisit pikaisen paluun.
Testaa kaatumiskyky skenaariona. Aloita vanhasta yhteensopivasta setistä, ennako yksi komponentti, tee edustava tilamuutos, sitten siirrä valittu komponentti takaisin. Määrittele odotettu tila: jatkuva yhteensopivuus, lukuturvallisuus, valvottu kieltäytyminen tai suunniteltu talteenotto. Tuloksen pitäisi nimetä, mitä tehtiin ja mitä simuloitiin. Arvostelun ei pitäisi koskaan erehtyä suunnittelukaaviosta suoritettavan rollback harjoitukset.
Pidä päätöstuloste lyhyenä ja konkreettisena. Julkaisutietue voi todeta: tuetut yhteensopivuusalueet, skenaariot, tunnetut suorittamatta olevat riskit, muutokset, jotka ovat vain eteenpäin, asennus portit, ja edellytykset pysäyttää. Se ei saisi vaatia yleistä turvallisuutta, koska matriisi läpäisi. Rehellinen tulos on todistetusti backed release rajan.
Jaa todisteet CI:ssä
Suorita pieni yhteensopivuus savu asetettu jokaisen muutoksen, joka koskee jaettuja sopimuksia. Suorita laajennettu sirpaleet, kun asiakas, protokolla, säästää, sisältö, kokoonpano, tai käyttöönotto koodi muuttuu. Jaa skenaarioperheen sijaan satunnaisia yhdistelmiä: tunnistautuminen ja istuntojen palauttaminen, osto ja oikeus, muuttoliike ja tallennettu tila, sisällön renderointi, ominaisuus gained käyttäytyminen, ja rollback. Tämä pitää epäonnistumiset mielekkäitä ja tekee kustannukset uuden ulottuvuuden näkyviin.
CI:n raportin tulisi säilyttää tuple testin alla ja tulosluokitus. Mukaan lukien asiakasrakenne, palvelun revisio, protokolla, sisältö ja konfiguraatio versiot, laite tai skenaario ID, ympäristötyyppi, ja ensimmäinen epäonnistunut yhteensopivuus sääntö. Vältä polkumyyntitili tai pelaaja tila. Kun skenaario simuloidaan, merkitse se. Kun skenaario toimii vastaan suoritettava adapteri tai hiekkalaatikko, merkintä, että myös. Todisteiden laatu on osa julkaisupäätöstä.
Tarkista nämä raportit julkaisun omistajien ennen laajentamista; yhteensopivuus näyttö on päätöspanos, ei koriste kojelauta.
Käytä vika Minimointi, kun matriisi tapauksessa rikkoutuu. Ensimmäinen epäonnistuva tuple voi sisältää tarpeettomia versioita tai liput. Pidä deterministinen ympäristö hiljaa, vähentää mittoja säilyttäen yhteensopivuus vika, ja tallentaa tuloksena minimaalinen skenaario regressio tapaus. Tämä tekee matriisi arvokkaampaa ajan sen sijaan, että tasaisesti tulossa meluisa kokoelma historiallisia onnettomuuksia.
Käytännön tarkistuslista
- Nimeä asiakas, palvelu, protokolla, skeema, sisältö, konfiguraatio, ja siirtymä mitat erikseen.
- Kirjoita tuettu, käännetty ja kielletty yhteensopivuus suhteet odotettuun käyttäytymiseen.
- Sisältää vanhimmat tuetut, uusimmat tuetut, siirtymä-, ja redulback-muotoinen skenaariot.
- Lisää nimetty moniulotteinen testit, joissa pairwise kattavuus on riittämätön.
- Testaa vanhat ja uudet asiakkaat luovat, lukevat ja palaavat saman palvelurajan yli.
- Käsittele katalogia ja konfiguraatiomuutoksia suoritettavina yhteensopivuusriippuvuutena.
- Ilmoitetaan ainoastaan eteenpäin suuntautuvat siirtymät ja esitetään vaiheittainen käyttöönotto- tai elvytyssuunnitelma.
- Tallenna, simuloidaanko näyttö, suoritetaanko se paikallisesti, hiekkalaatikkoon vai ulkoisesti todennetaan.
- Säilytä minimaalinen epäonnistuminen tuple tarkistettuna regressio skenaario.
Usein kysytyt kysymykset
Riittääkö parillinen testaus julkaisuyhteensopivuuteen?
Parillinen kattavuus on hyödyllinen tapa vähentää suurta matriisia, mutta se ei voi todistaa kaikkia moniulotteisia rajoitteita. Käytä sitä laajaan vuorovaikutukseen, sitten lisää selkeitä skenaarioita korkean riskin yhdistelmille, kuten migroitu tila plus uusi sisältö plus vanha asiakas, tai rollback kun konfiguraatio portti on muuttunut.
Milloin vanha asiakas pitäisi estää?
Estä se ennen mutaatiota, kun se ei pysty turvallisesti tulkitsemaan vaadittua sisältöä, täyttämään protokollasopimusta tai lukemaan nykyistä tilaa koskevaa rajaa. Selkeä päivitysvaatimus on turvallisempi kuin jatkaa oletuksella, joka muuttaa merkitystä. Tarkka käytäntö on tuotekohtainen, mutta kunto ja käyttäjälähtöinen käyttäytyminen on testattava yhdessä.
Voiko ominaisuus lippu ratkaista yhteensopivuuden itse?
Ei. Lippu voi hallita altistumista, mutta se ei voi tehdä yhteensopimaton protokolla, skeema, tai sisältö ennätys turvallinen. Testaa liput välimuistissa ja päivitetty tila, sen riippuvuus asiakkaan ominaisuuksia, ja mitä tapahtuu, jos se muuttuu istunnon ollessa aktiivinen.
Mitä tämä tarkoittaa Persistium:ssä?
Persistium on kehitteillä oleva paikallinen ja ensimmäinen luotettavuustuoteperhe. Tässä artikkelissa kuvataan testi-suunnittelua, ei väitettä, että julkaistu tuote luo automaattisesti jokaisen matriisin tai tarjoaa isännöidyn julkaisun hallinnan. Jatkossa tutkitaan rajallisia todisteita tässä kuvatuista yhteensopivuuspäätöksistä.
