Een softwarerelease met databasewijziging voorbereiden

Een softwarerelease wijzigt soms applicatie en database tegelijk. De rollback moet daarom meer omvatten dan de vorige programmaversie. Leg vast welke combinatie van code, configuratie en gegevensstructuur samenwerkt.

Het onderstaande hypothetische portaalvoorbeeld is een geplande proef. Het beschrijft geen wijziging aan een echte klantdatabase.

De rollback op dezelfde gegevensstand testen

De bestaande applicatie V1 leest klantnamen uit customer_name. De nieuwe applicatie V2 moet display_name gaan lezen. In het aanvankelijke plan wordt de oude kolom verwijderd. Daarna start de nieuwe applicatie niet door ontbrekende configuratie.

Oude code opnieuw uitrollen draait de gegevensstructuur niet terug. Een rollbackknop in het uitrolhulpmiddel lost deze onverenigbaarheid niet vanzelf op.

Een verenigbare overgang plannen

Een mogelijke route is stapsgewijs: behoud eerst de oude kolom en voeg de nieuwe toe. Bestaande waarden worden navolgbaar overgezet. Het team legt vast welk veld leidend is en hoe wijzigingen tijdens de overgang consistent blijven.

Test in een aparte omgeving beide applicatieversies met deze tussenstand. Wijzig daarbij een naam en lees die via beide versies correct terug. Eenmalig kopiëren volstaat niet als latere waarden maar in één veld terechtkomen.

Plan de verwijdering van het oude veld pas wanneer de overgang is bevestigd en de oude versie niet meer nodig is voor een rollback. Daardoor verandert opnieuw welke oudere versies nog bruikbaar zijn. Die stap vraagt een apart besluit.

Gegevens na de overgang meenemen

Een oudere back-up kan de vorige structuur bevatten. Als intussen nieuwe bestellingen zijn aangenomen, kunnen die ontbreken in de back-up. Herstel mag zulke transacties niet ongemerkt weggooien. Welke gegevens later binnenkomen en hoe ze worden vergeleken, hoort in het herstelplan.

Afhankelijk van de wijziging kan een gepland onderhoudsvenster of een gerichte correctie in de nieuwe versie beter passen. De stapsgewijze overgang belooft niet in het algemeen een ononderbroken update.

De proefuitkomst vastleggen

Documenteer de geteste versie, configuratie, gegevensstand en wie bij fouten beslist. Volg in de test een bestelling tot bevestiging in het doel en oefen daarna de bedoelde rollback. Noteer welke gegevens behouden blijven en welke beperkingen gelden.

Zo wordt vóór de productieovergang zichtbaar of de geplande rollback werkelijk bij applicatie en gegevens past.

Bronnen

• Prisma — Expand-and-contract migrations

• GitLab — Environments