Forbered en softwarerelease med databaseændring

En softwarerelease ændrer nogle gange både applikation og database. Tilbagevejen skal derfor tage højde for mere end den tidligere programversion. Notér, hvilken kombination af kode, konfiguration og datastruktur der fungerer sammen.

Det hypotetiske portaleksempel nedenfor er en planlagt test. Det beskriver ingen ændring af en virkelig kundedatabase.

Test tilbagevejen mod samme datatilstand

Den eksisterende applikation V1 læser kundenavne fra customer_name. Den nye applikation V2 skal i stedet læse display_name. I den oprindelige plan fjernes den gamle kolonne. Derefter starter den nye applikation ikke på grund af manglende konfiguration.

Genudrulning af gammel kode gendanner ikke datastrukturen. En rollbackknap i værktøjet løser ikke selv denne uforenelighed.

Planlæg en kompatibel overgang

Et muligt alternativ er en trinvis overgang: Bevar først den gamle kolonne, og tilføj den nye. Eksisterende værdier overføres sporbart. Teamet fastlægger, hvilket felt der er autoritativt, og hvordan ændringer forbliver konsistente under overgangen.

Test begge applikationsversioner mod denne mellemtilstand i et separat miljø. Det omfatter at ændre et navn og læse det korrekt via begge versioner. En enkelt kopiering er ikke nok, hvis senere værdier kun skrives i ét felt.

Planlæg først fjernelse af det gamle felt, når overgangen er bekræftet, og den gamle version ikke længere er nødvendig som tilbagevej. Dermed ændres igen, hvilke ældre versioner der kan bruges. Trinnet kræver sin egen beslutning.

Medtag data efter skiftet

En ældre backup kan indeholde den tidligere struktur. Er nye ordrer blevet accepteret imens, kan de mangle i backuppen. Gendannelse må ikke kassere dem ubemærket. Hvilke data der kommer til, og hvordan de afstemmes, hører til gendannelsesplanen.

Afhængigt af ændringen kan et planlagt vedligeholdelsesvindue eller en målrettet rettelse i den nye version passe bedre. Den trinvise overgang er ikke et generelt løfte om en opdatering uden afbrydelser.

Registrér prøvens resultat

Dokumentér testet version, konfiguration, datatilstand og den person, der beslutter ved fejl. Følg en ordre til bekræftelse i målet i testen, og gennemspil derefter tilbagevejen. Notér bevarede data og begrænsninger.

Så bliver det før produktionsskiftet synligt, om den planlagte tilbagevej faktisk passer til applikation og data.

Kilder

• Prisma — Expand-and-contract migrations

• GitLab — Environments