WordPress sites die op een snelle infrastructuur draaien, kunnen nog steeds betrouwbaarheidsproblemen hebben, vooral omdat die infrastructuur alleen bepaalt hoe snel pagina’s laden. Het is het veranderingsbeheerproces van je bedrijf dat bepaalt of de site blijft werken nadat iemand een plugin heeft bijgewerkt, een nieuw ontwerp heeft uitgerold of de PHP-versie heeft geüpgraded.

Daarom is het proces van het controleren, testen, goedkeuren en herstellen van wijzigingen in een productieomgeving een van de belangrijkste criteria waarmee bedrijfsteams hostingplatforms beoordelen.

Een platform dat geen gestructureerd wijzigingsproces ondersteunt, dwingt teams om zelf controles in te bouwen: handmatige backups vóór updates die via chat worden doorgegeven, informele goedkeuringsstappen en brandjes blussen na de deploy, waardoor engineers steeds weer van hun projectwerk worden weggehaald.

Waarom wijzigingsrisico de grootste zorg is voor bedrijven

De omvang van de wijzigingen die een WordPress-omgeving gedurende haar levensduur nodig heeft, is groter dan het op het eerste gezicht lijkt. Bijvoorbeeld:

• Core-releases verschijnen meestal volgens een vast schema.
• Pluginupdates kunnen bij een complexe installatie oplopen tot tientallen per maand.
• Upgrades van de PHP-versie hebben invloed op de hele uitvoeringsomgeving.
• Wijzigingen in het databaseschema gaan gepaard met grote pluginversies en kunnen conflicteren met aanpassingen die op de vorige structuur zijn gebaseerd.

Bij bedrijven waar WordPress een klantenportaal, een voor compliance cruciale contentworkflow of een omzetrijk e-commerceplatform aandrijft, heeft elke wijziging invloed op talloze afhankelijkheden die niet altijd gedocumenteerd zijn. Maar als er iets misgaat, ligt de oorzaak vaak bij een deploy die zonder betrouwbaar testtraject verloopt, en niet bij de infrastructuur.

Als een hostingprovider geen geformaliseerde testomgevingen, rollback-trajecten of toegangscontroles heeft, is het aan jouw team om die zelf op te zetten. De belangrijkste vragen zijn dus of de deploy voorspelbaar is en of herstel daardoor snel verloopt.

Hoe testomgevingen een veilig testtraject creëren vóór de productie

MyKinsta geeft je de tools om van een gedisciplineerd wijzigingsproces de norm te maken in plaats van een extra last, dankzij testomgevingen, Selective Push, gelaagde backups en rolgebaseerde toegangscontroles.

Elk Kinsta-pakket bevat één gratis, gecontaineriseerde standaard testomgeving per site. Om er een aan te maken, ga je naar Sites, selecteer je de site die je wilt stagen, klik je op de omgevingskiezer (bijvoorbeeld Live) en kies je Nieuwe omgeving aanmaken. Je kunt de bestaande live-omgeving klonen, een lege WordPress-instantie installeren of een lege omgeving aanmaken voor een aangepaste opzet.

Het venster Nieuwe omgeving aanmaken in MyKinsta.

De Premium testomgeving add-on van Kinsta biedt tot vijf premium testomgevingen per site, bovenop de ene gratis standaardomgeving die bij elk pakket is inbegrepen. Dit is ideaal als je parallelle ontwikkelingsstromen hebt, resource-intensieve functionaliteit moet testen of werkt onder omstandigheden die moeten overeenkomen met de productieomgeving. Het is de moeite waard om de verschillen tussen de twee omgevingstypen te begrijpen bij het in kaart brengen van je workflow:

• Standaard testomgeving draait altijd op één CPU en heeft een vaste RAM-toewijzing. Servercaching is beschikbaar zonder ondersteuning voor CDN of edge-caching. Dit is geschikt voor pluginupdates, ontwerpbeoordelingen en het testen van contentworkflows.
• Premium testomgeving komt overeen met het resourceprofiel van je live-container en biedt je zowel CDN-beschikbaarheid als ondersteuning voor edge-caching. Je gebruikt dit wanneer tests te maken hebben met configuraties met veel verkeer, WooCommerce-integraties of gedrag dat alleen aan het licht komt bij belastingen op productieschaal.

Voor updates van plugins of thema’s moet je testworkflow het volgende bevatten: de update uitvoeren, elk integratiepunt controleren waarop deze invloed kan hebben, goedkeuring verzamelen van de relevante belanghebbenden, en pas daarna de push naar productie voorbereiden. Dit is eenvoudig te handhaven wanneer test en productie aparte omgevingen zijn.

Kinsta-klant Itineris bouwt de workflows voor zijn zakelijke klanten rond de testinfrastructuur van Kinsta:

Testomgevingen, geautomatiseerde backups en een robuuste infrastructuur waren essentieel voor het stroomlijnen van onze workflows en het verbeteren van de prestaties van onze sites.

Hoe Selective Push de omvang van elke deployment bepaalt

Een testomgeving neemt risico’s uit de testfase weg, maar het pushen van de hele testomgeving naar productie brengt een ander risico met zich mee. Nu wordt elk bestand en elke databasetabel vervangen, inclusief wijzigingen die geen deel uitmaken van de beoogde deploy (zoals testcontent).

Het dialoogvenster Push-omgeving in MyKinsta.

Met Selective Push bepaal je zelf precies wat er van de testomgeving naar de productieomgeving gaat. Om dit te gebruiken, selecteer je je testomgeving in MyKinsta, klik je op Push-omgeving en kies je een deploybereik:

• Bestanden. Hiermee worden thema’s, plugins en codewijzigingen doorgestuurd, terwijl de live-database intact blijft. Gebruik dit als de testdatabase niet synchroon loopt met de productiegegevens, of als de wijziging alleen de codebase betreft.
• Database. Hiermee kun je databasewijzigingen doorvoeren terwijl de productiebestanden ongewijzigd blijven. Gebruik dit voor structurele wijzigingen, zoals updates van aangepaste berichttypen of pluginconfiguraties die in de database zijn opgeslagen.

Je hebt ook dropdownmenu’s om de push verder te finetunen. Je kunt bijvoorbeeld specifieke bestanden, mappen of databasetabellen selecteren.

Voor elke push naar een live-omgeving maakt Kinsta automatisch een door het systeem gegenereerde backup van de productieomgeving, die de toestand vlak voor de deploy vastlegt. Deze is beschikbaar als herstelpunt zodra de push is voltooid. Als de push een onverwacht resultaat oplevert, is het terugdraaien een enkele handeling in MyKinsta in plaats van een reconstructie vanuit een backup.

De zoek-en-vervang-stap

Als de deploy een wijziging in de URL-structuur of een domeinwissel inhoudt, bevat de database verwijzingen naar de testsite-URL. Met de zoek-en-vervang-tool van MyKinsta kun je dit soort wijzigingen bijwerken.

Let op: de optie Zoeken en vervangen uitvoeren in het dialoogvenster Push-omgeving werkt alleen op de database, dus je moet een extra stap uitvoeren voor bestanden en mappen. Dit doe je via het scherm Tools in MyKinsta voor een site, waar je de tool Zoeken en vervangen vindt.

Voer hier de staging-URL in het veld Zoeken in en de productie-URL in het veld Vervangen door. Zodra je op Vervangen klikt, maakt MyKinsta een door het systeem gegenereerde backup en voert vervolgens het zoeken en vervangen uit.

De tool Zoeken en vervangen in MyKinsta.

Alles bij elkaar zorgen selectief pushen, backups vóór het pushen en een speciale zoek-en-vervang-stap ervoor dat de testomgeving een proces wordt met verplichte controlepunten in elke fase.

Hoe gelaagde backups de gevolgen van een mislukte wijziging beperken

Zelfs met een testomgeving en een workflow voor selectief pushen kunnen sommige wijzigingen tot onvoorspelbare fouten leiden. Zo kan een API van een derde partij zich anders gedragen met productie-inloggegevens dan binnen de testomgeving.

Backups kunnen je helpen de gevolgen te beperken als dit gebeurt. Voor een site in MyKinsta ga je naar het scherm Backups om ze allemaal te bekijken:

Het tabblad Backups in MyKinsta.

Kinsta dekt elke fase van de deploycyclus met vier soorten backups:

• Dagelijkse backups worden automatisch uitgevoerd en blijven 14–30 dagen bewaard, afhankelijk van je pakket. Elke backup is een volledige momentopname van een site.
• Door het systeem gegenereerde backups worden automatisch geactiveerd vóór belangrijke bewerkingen, zoals het overzetten van de testomgeving naar de live-omgeving, het toepassen van een plugin- of thema-update, het terugzetten van een backup, het uitvoeren van een zoek-en-vervang-actie en het resetten van een site. Er worden altijd automatisch herstelpunten aangemaakt voordat een bewerking wordt uitgevoerd.
• Met handmatige backups kun je op elk moment tot vijf extra gemarkeerde momentopnames maken via het tabblad Handmatig (het beschikbare aantal hangt af van je pakket). Deze zijn bedoeld voor bewerkingen die buiten het geautomatiseerde schema vallen, zoals een upgrade van de PHP-versie of een databasemigratie die je via WP-CLI uitvoert.
• Backups per uur zijn beschikbaar als betaalde add-on in twee niveaus: backups met een interval van 6 uur en echte backups per uur. Kijk op de add-onspagina voor de huidige prijzen.

Door op de knop Herstellen naar voor een backup te klikken en vervolgens de doelomgeving te kiezen, kun je terugkeren naar die specifieke backup. Zodra het herstel is voltooid, genereert MyKinsta een nieuwe systeembackup die de toestand weergeeft van vlak voordat het herstel werd uitgevoerd.

De vervolgkeuzelijst Herstellen naar in MyKinsta.

Door rond dit soort functionaliteit een proces voor wijzigingsbeheer op te zetten, worden geplande onderhoudsvensters en formele rollbacks teruggebracht tot één enkele, uitvoerbare workflow binnen MyKinsta. Zo heeft Konica Minolta zijn marketingsite in drie maanden tijd gemigreerd naar WordPress op Kinsta en de betrouwbaarheid van deploys als de basis van het project aangemerkt:

Onze grootste zorg was downtime en prestatieverlies tijdens de migratie, maar het team van Kinsta heeft alles soepel afgehandeld zonder enige onderbreking.

Hoe rolgebaseerde toegang het veranderingsproces binnen teams waarborgt

Bij deployments binnen grote bedrijven zijn er meestal meerdere belanghebbenden betrokken met verschillende verantwoordelijkheden in elke fase van het veranderingsproces.

Ontwikkelaars hebben bijvoorbeeld toegang nodig tot de testomgeving om wijzigingen te bouwen en te testen, terwijl QA-engineers die wijzigingen moeten valideren. Verderop in het proces moeten projectmanagers inzicht hebben in wat er in de testomgeving staat, zonder dat ze dit naar de productieomgeving kunnen pushen, en moeten reviewers aan de klantzijde de status van de testomgeving goedkeuren.

Met het toegangsmodel en gebruikersbeheer van Kinsta kun je zes rollen definiëren en afdwingen, hoewel er voor verandermanagement op bedrijfsniveau drie relevanter zijn:

• Bedrijfsontwikkelaars kunnen alle sites en testomgevingen beheren, hebben toegang tot DNS, kunnen analytics bekijken en een testomgeving naar live pushen. Ze hebben geen toegang tot factuurgegevens, kunnen geen migraties goedkeuren en geen betaalde add-ons toevoegen of verwijderen. Deze rol is geschikt voor interne ontwikkelaars en technische leiders met volledige deploybevoegdheid.
• Sitebeheerders hebben volledige controle over een specifieke site en al zijn omgevingen. Ze kunnen echter geen site uit het bedrijfsaccount verwijderen of premium testomgevingen aanmaken en verwijderen. Deze rol is geschikt voor technische stakeholders die verantwoordelijk zijn voor een specifiek project.
• Siteontwikkelaars hebben toegang tot alle testomgevingen voor de sites die aan hen zijn toegewezen, maar kunnen geen testomgeving naar productie pushen. Voor een freelancer die aan een feature-branch werkt, of een QA-engineer die een release-kandidaat valideert, geeft deze rol toegang tot het deel van de workflow dat bij hun functie hoort.

Met MyKinsta kun je heel eenvoudig een gebruiker uitnodigen via de pagina Bedrijfsinstellingen > Gebruikers. Hier kun je via de knop Gebruikers uitnodigen hun e-mailadres invoeren en kiezen of je toegang op bedrijfs- of siteniveau wilt verlenen.

Toegang centraliseren met SAML SSO

Als je een onderneming bent die de toegang tot meerdere tools beheert via een centrale identiteitsprovider, ondersteunt Kinsta SAML SSO met elke identiteitsprovider (IdP) die de SAML-standaard gebruikt. Dit bevat onder andere Microsoft Entra ID, Okta, Google Workspace en vele anderen.

Om dit in te schakelen, ga je in MyKinsta naar Bedrijfsinstellingen > Single sign-on en klik je op Inschakelen. Vervolgens configureer je de SAML-applicatie in je IdP met behulp van de verbindingsgegevens die MyKinsta verstrekt, waarna je teruggaat naar MyKinsta om de installatie te voltooien met de SSO-URL, Entity ID en het openbare certificaat van je IdP.

Het instellingsscherm voor Single Sign-On in MyKinsta.

Zodra dit actief is, logt een gebruiker via je IdP in met de bestaande inloggegevens van het bedrijf. Door verplichte SSO in te schakelen, voorkom je dat gebruikers de IdP omzeilen door rechtstreeks in te loggen. Als iemand de organisatie verlaat, wordt zijn of haar toegang in de IdP ingetrokken, waardoor deze tegelijkertijd ook uit MyKinsta wordt verwijderd, via hetzelfde proces dat voor alle andere tools in de stack wordt gebruikt.

Tot slot is tweefactorauthenticatie (2FA) standaard verplicht voor alle accounts die niet onder SAML SSO vallen. Een bedrijfseigenaar kan de 2FA-methode van elke gebruiker bekijken via het scherm Bedrijfsinstellingen > Gebruikers > 2FA.

Verandermanagement is hoe WordPress voor bedrijven veilig schaalbaar is

Voor grote organisaties is het hostingplatform de infrastructuur die bepaalt hoe veilig een WordPress-omgeving kan veranderen, niet alleen hoe snel deze draait. Wat platforms op het niveau van managed hosting van elkaar onderscheidt, is of een team een WordPress-update kan deployen met een betrouwbaar herstelpad voor het geval er iets misgaat.

De testomgevingen, Selective Push, het gelaagde backupsysteem en de rolgebaseerde toegangscontroles van Kinsta geven bedrijfsteams de tools om een gedisciplineerde wijzigingsworkflow te hanteren zonder dat ze die controles zelf hoeven te onderhouden.

Om te zien hoe dit er voor jouw organisatie uitziet, kun je de zakelijke WordPress-hostingopties van Kinsta bekijken om te ontdekken of je je huidige proces voor wijzigingsbeheer moet herzien.