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.

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
Läs vidare
Alla artiklar



Cloud & drift med ASES
Hosting, driftsättning, underhåll och support

