Hoppa till innehållet

Förbered en programvarurelease med databasändring

Att rulla tillbaka koden gör den inte automatiskt förenlig med en ändrad databas. Ett fullständigt testfall visar vad som ska kontrolleras vid byte och återgång.

Philipp Reuter2 min läsning
Programvarukontakt med lila detaljer och kodsymbol samt två separata ringar med olika formade urtag.

En programvarurelease ändrar ibland både applikation och databas. Återgången behöver därför omfatta mer än den tidigare programversionen. Dokumentera vilken kombination av kod, konfiguration och datastruktur som fungerar ihop.

Det hypotetiska portalexemplet nedan är ett planerat testfall. Det beskriver ingen ändring av en verklig kunddatabas.

Testa återgången mot samma datatillstånd

Den befintliga applikationen V1 läser kundnamn från customer_name. Den nya applikationen V2 ska i stället läsa display_name. I den ursprungliga planen tas den gamla kolumnen bort. Därefter startar den nya applikationen inte på grund av saknad konfiguration.

Steg

Databas efter steget

Resultat i exemplet

Före bytet

Gammal namnkolumn finns

Befintlig applikation fungerar

Efter den planerade ändringen

Bara den nya namnkolumnen finns

Ny applikation startar inte på grund av konfigurationen

Driftsätt bara den gamla koden igen

Fortfarande bara den nya namnkolumnen

Gammal applikation hittar inte den förväntade kolumnen

Att driftsätta gammal kod igen återställer inte datastrukturen. En rollbackknapp i verktyget löser inte själv den oförenligheten.

Planera en kompatibel övergång

Ett möjligt alternativ är stegvis: Behåll först den gamla kolumnen och lägg till den nya. Befintliga värden överförs spårbart. Teamet fastställer vilket fält som är styrande och hur ändringar förblir konsekventa under övergången.

Testa båda applikationsversionerna mot mellanläget i en separat miljö. Ändra ett namn och läs tillbaka det korrekt genom båda versionerna. En engångskopiering räcker inte om senare värden bara skrivs i ett fält.

Planera borttagningen av det gamla fältet först när övergången är bekräftad och den gamla versionen inte längre behövs för återgång. Därmed ändras åter vilka äldre versioner som är användbara. Steget behöver ett eget beslut.

Ta hänsyn till data efter bytet

En äldre säkerhetskopia kan innehålla den tidigare strukturen. Om nya beställningar har tagits emot under tiden kan de saknas i kopian. Återställning får inte tyst kasta bort dem. Vilka data som tillkommer och hur de stäms av hör till återställningsplanen.

Beroende på ändringen kan ett planerat underhållsfönster eller en riktad rättning i den nya versionen passa bättre. Den stegvisa övergången är inget allmänt löfte om en uppdatering utan avbrott.

Dokumentera provets resultat

Dokumentera testad version, konfiguration, datatillstånd och vem som beslutar vid fel. Följ i test en beställning till bekräftelse i målet och spela sedan igenom återgången. Anteckna bevarade data och begränsningar.

Då syns före produktionsbytet om den planerade återgången faktiskt passar applikationen och dess data.

Källor

Skriven av

  • Philipp ReuterRedaktör för mjukvarukvalitetPhilipp Reuter skriver om mjukvarutestning och förberedelse av nya releaser på ASES. Hans artiklar handlar om felanalys, acceptanstester och granskning av ändringar i befintliga applikationer.

Följ ASES

Läs vidare

Alla artiklar

Cloud & drift med ASES

Hosting, driftsättning, underhåll och support