Een WordPress-deployment kan meer veranderen dan alleen de bestanden van een release. Een pluginupdate of maatwerkontwikkeling kan ook tabellen aanmaken, opties wijzigen, records transformeren of de manier veranderen waarop bestaande gegevens worden geïnterpreteerd. Als de code en database niet langer compatibel zijn, kan de site uitvallen, ook wanneer het kopiëren van de bestanden voltooid lijkt.
Het beheren van een WordPress-deployment met databasewijzigingen vereist dat elke wijziging wordt behandeld op basis van de impact en omkeerbaarheid ervan. Het doel is niet alleen code publiceren: het gaat om een gecontroleerde overgang, het controleren van kritieke processen en weten wat te doen als de nieuwe versie niet naar verwachting werkt.
Waarom het herstellen van bestanden de site niet altijd herstelt
De code voert bewerkingen uit op de database, maar bevat niet noodzakelijk de huidige staat daarvan. Als een nieuwe versie een tabel aanmaakt of de indeling van een waarde wijzigt, maken de vorige bestanden die veranderingen niet ongedaan. De oude code herkent het nieuwe schema mogelijk niet, of de site kan gegevens hebben ontvangen die de vorige versie niet kan verwerken.
Het omgekeerde kan ook gebeuren: een eerdere database herstellen terwijl de nieuwe bestanden behouden blijven, kan het systeem in een inconsistente staat achterlaten. In WooCommerce kunnen bestellingen en andere operationele gegevens bijvoorbeeld tijdens en na de deployment blijven veranderen. Een eerdere databaseback-up terugzetten kan legitieme bewerkingen verwijderen die zijn uitgevoerd sinds die back-up werd gemaakt.
Maak daarom onderscheid tussen code terugrollen, waarbij de bestanden naar een eerdere versie worden teruggezet; gegevensreparatie, waarbij specifieke wijzigingen worden gecorrigeerd; en terugzetten van een back-up, waarbij een back-up wordt hersteld. Dit zijn geen gelijkwaardige acties en ze hebben niet dezelfde kosten of impact.
Wijzigingen en afhankelijkheden inventariseren vóór publicatie
Leg vóór de deployment vast wat er verandert en waar. Een bruikbare lijst onderscheidt vier categorieën:
- Code: thema's, plugins, maatwerkcode, geplande taken en afhankelijkheden.
- Schema: tabellen, kolommen, indexen en andere structuren die worden aangemaakt, gewijzigd of verwijderd.
- Gegevens: records die worden ingevoegd, bijgewerkt, getransformeerd of verwijderd, inclusief opties en metadata.
- Configuratie en content: omgevingsspecifieke waarden, inloggegevens, regels, pagina's of instellingen die via het beheerpaneel worden beheerd.
Documenteer wie elke migratie uitvoert, wanneer deze wordt uitgevoerd en of deze veilig kan worden herhaald. Controleer of de migratie automatisch wordt geactiveerd bij het bijwerken van een plugin, of dat er een opdracht, handmatige taak of beheeractie nodig is. Breng ook de afhankelijkheden in kaart: welke codeversie de nieuwe structuur nodig heeft en welke processen naar de betrokken tabellen schrijven.
In WordPress kan een deel van de configuratie in de database staan en verschillen tussen productie en testomgevingen. Ga er niet van uit dat het kopiëren van een database van de ene omgeving naar de andere zonder gevolgen is. Geserialiseerde gegevens of gegevens die als opties zijn opgeslagen, kunnen bovendien een transformatie vereisen die compatibel is met hun indeling, in plaats van een ongerichte tekstvervanging.
Een compatibele, gefaseerde volgorde ontwerpen
Gebruik waar mogelijk een expand-and-contract-strategie. Voeg eerst structuren toe die compatibel zijn met de huidige versie; deploy vervolgens code die met zowel de oude als de nieuwe toestand kan werken; migreer daarna de gegevens en valideer het resultaat. Pas wanneer de nieuwe versie stabiel is, verwijder je oude kolommen, routes of structuren die niet meer nodig zijn.
Deze volgorde verkleint het risico dat een rollback van bestanden de site zonder een structuur achterlaat die de oude code verwacht. Niet alle wijzigingen kunnen op deze manier worden uitgevoerd: een destructieve transformatie of incompatibele wijziging kan een onderhoudsvenster, het blokkeren van schrijfbewerkingen of specifieke stappen van de pluginleverancier vereisen. De keuze hangt af van de bewerking, de hoeveelheid gegevens, de verwachte duur en de mogelijkheid om de dienstverlening in stand te houden.
Combineer geen codewijzigingen, migraties en onomkeerbare opschoning in één bewerking zonder controlepunten. Als een taak lang duurt of halverwege mislukt, moet duidelijk zijn welke stappen zijn voltooid. Bepaal hoe de taak veilig kan worden hervat, hoe dubbele uitvoeringen worden voorkomen en wie toestemming geeft om door te gaan. Controleer bij gefaseerde deployments of de versies die naast elkaar draaien met de gedeelde database kunnen werken.
Testen in een representatieve omgeving
Een testomgeving is waardevol als deze relevante omstandigheden nabootst: PHP- en WordPress-versies, plugins, integraties, configuratie en gegevenstypen. De omgeving hoeft niet alle echte gegevens te kopiëren, maar moet wel de betrokken processen kunnen testen. Als je productiegegevens gebruikt, bescherm dan persoonsgegevens en beperk de toegang; een kopie moet met dezelfde voorzorgsmaatregelen worden behandeld als de bron.
Oefen de migratie en meet hoelang deze duurt met een redelijk representatieve hoeveelheid gegevens. Controleer wat er gebeurt als de migratie wordt onderbroken en of deze kan worden herhaald zonder records te dupliceren of gegevens te verliezen. Valideer daarna ten minste het lezen en schrijven van de betrokken gegevens en de relevante bedrijfsprocessen: aankoop, betaling, bevestiging, orderbeheer of synchronisatie met externe systemen, afhankelijk van de situatie.
Neem compatibiliteit, rechten, geplande taken en integratiefouten mee in de tests. Dat de homepage laadt, bewijst niet dat het aankoopproces werkt. Als je een integratie niet in de testomgeving kunt nabootsen, bepaal dan een alternatieve controle en wie die na publicatie uitvoert.
Signalen na de deployment vaststellen
Bepaal vóór de start wat een geslaagde deployment inhoudt en hoelang deze wordt gemonitord. De signalen moeten aansluiten op de vastgestelde risico's en mogen niet beperkt blijven tot controleren of de server reageert. Denk bijvoorbeeld aan:
- PHP-fouten, applicatielogs en fouten in geplande taken.
- Resultaten van de migratie: de verwachte structuur, aantallen of consistentie van de betrokken records.
- Lees- en schrijfbewerkingen en de uitvoering van kritieke processen.
- De status van betalingen, webhooks, synchronisaties en andere betrokken integraties.
- Gebruikelijke bedrijfsindicatoren, vergeleken met het verwachte gedrag in die context.
Wijs verantwoordelijken aan die deze signalen beoordelen en drempelwaarden voor pauzeren of terugrollen vaststellen. Als een fout toeneemt, bepaal dan eerst of deze de applicatie, de integratie of de gegevens betreft; een waarschuwing zonder responsprocedure is niet voldoende om het risico te beheersen.
Herstel voorbereiden en besluiten of de deployment wordt goedgekeurd
Het plan moet aangeven wat veilig kan worden teruggedraaid en waarvoor gegevensreparatie of het terugzetten van een back-up nodig is. Controleer of back-ups bestaan en kunnen worden hersteld; een niet-geteste back-up biedt geen operationele garantie. Bepaal het herstelpunt, de afhankelijkheden van de procedure en de gevolgen van het weggooien van legitieme wijzigingen die na de back-up zijn gedaan. Beoordeel bij een actieve webshop hoe je bestellingen en bewerkingen bewaart die tijdens de ingreep binnenkomen.
Spreek vóór publicatie af wie beslist, wie uitvoert en wie valideert. Geef alleen toestemming voor de deployment als de migratie is getest, de afhankelijkheden in kaart zijn gebracht, er verantwoordelijken voor de controles zijn aangewezen en herstel haalbaar is. Pauzeer als er twijfel bestaat over de compatibiliteit tussen versies, als een kritieke test mislukt of als lopende activiteit niet kan worden beschermd. Rol code terug wanneer dat voldoende is om de compatibiliteit te herstellen; repareer gegevens wanneer het probleem duidelijk is afgebakend; zet alleen een back-up terug als bekend is welke latere wijzigingen daardoor verloren zouden gaan.
Go/no-go-checklist vóór publicatie: volledige inventarisatie; geverifieerde back-up; volgorde en onderhoudsvenster bepaald; tests geslaagd; signalen en verantwoordelijken toegewezen; en expliciete criteria om door te gaan, te pauzeren of te herstellen. Die discipline maakt van een databasewijziging een gecontroleerde operatie, in plaats van een gok dat oude bestanden voldoende zijn.
