Forbered en release med databaseendring
Å rulle tilbake koden gjør den ikke automatisk kompatibel med en endret database. Et fullstendig testtilfelle viser hva som må kontrolleres ved bytte og retur.
En release endrer noen ganger både applikasjon og database. Returveien må derfor omfatte mer enn den forrige programversjonen. Noter hvilken kombinasjon av kode, konfigurasjon og datastruktur som fungerer sammen.
Det hypotetiske portaleksemplet nedenfor er et planlagt testtilfelle. Det beskriver ingen endring av en virkelig kundedatabase.
Test returen mot samme datatilstand
Den eksisterende applikasjonen V1 leser kundenavn fra customer_name. Den nye applikasjonen V2 skal i stedet lese display_name. I den opprinnelige planen fjernes den gamle kolonnen. Deretter starter ikke den nye applikasjonen på grunn av manglende konfigurasjon.
Trinn | Database etter trinnet | Resultat i eksemplet |
|---|---|---|
Før byttet | Gammel navnekolonne finnes | Eksisterende applikasjon fungerer |
Etter den planlagte endringen | Bare den nye navnekolonnen finnes | Ny applikasjon starter ikke på grunn av konfigurasjonen |
Rull ut bare den gamle koden igjen | Fortsatt bare den nye navnekolonnen | Gammel applikasjon finner ikke forventet kolonne |
Å rulle ut gammel kode igjen gjenoppretter ikke datastrukturen. En rollbackknapp i verktøyet løser ikke selv denne uforenligheten.
Planlegg en kompatibel overgang
Et mulig alternativ er trinnvis: Behold først den gamle kolonnen og legg til den nye. Eksisterende verdier overføres sporbart. Teamet fastsetter hvilket felt som er styrende, og hvordan endringer holdes konsistente under overgangen.
Test begge applikasjonsversjonene mot mellomtilstanden i et separat miljø. Endre et navn og les det riktig tilbake gjennom begge versjonene. En engangskopiering er ikke nok hvis senere verdier bare skrives i ett felt.
Planlegg fjerningen av det gamle feltet først når overgangen er bekreftet og gammel versjon ikke lenger trengs som returvei. Da endres igjen hvilke eldre versjoner som kan brukes. Trinnet trenger sin egen beslutning.
Ta med data etter byttet
En eldre sikkerhetskopi kan inneholde den tidligere strukturen. Hvis nye bestillinger er mottatt i mellomtiden, kan de mangle i kopien. Gjenoppretting må ikke forkaste dem ubemerket. Hvilke data som kommer til, og hvordan de avstemmes, hører til gjenopprettingsplanen.
Avhengig av endringen kan et planlagt vedlikeholdsvindu eller en målrettet rettelse av den nye versjonen passe bedre. Den trinnvise overgangen er ikke et generelt løfte om oppdatering uten avbrudd.
Registrer prøvens resultat
Dokumenter testet versjon, konfigurasjon, datatilstand og hvem som bestemmer ved feil. Følg i test en bestilling frem til bekreftelse i målet, og spill deretter gjennom returen. Noter bevarte data og begrensninger.
Da blir det synlig før produksjonsbyttet om den planlagte returen faktisk passer til applikasjonen og dataene.
Kilder
Les videre
Alle artikler
Sky og drift med ASES
Hosting, utrulling, vedlikehold og oppfølging