Op de live site werken is opereren zonder oefening. Meestal gaat het goed. Tot het een keer niet goed gaat.
Het scenario is herkenbaar voor iedereen die weleens een site heeft beheerd. Er moet een plugin bijgewerkt, een functie aangepast of een instelling gewijzigd. Het is een kleine ingreep, dus waarom moeilijk doen: even op de live site. Negen van de tien keer gaat dat goed. De tiende keer staat de site op wit, midden op een doordeweekse dag, en begint het zweten.
Professionele teams werken daarom nooit rechtstreeks op de live omgeving. Niet omdat ze hun werk niet vertrouwen, maar juist omdat ze weten dat élke wijziging kan verrassen. Een update van de ene plugin die botst met de andere. Een aanpassing die op desktop prima werkt en op mobiel iets sloopt. Dat wil je ontdekken op een plek waar niemand er last van heeft.
Wat een testomgeving is
Een testomgeving (ook wel staging genoemd) is een exacte kopie van je live site, op een afgeschermde plek. Zelfde thema, zelfde plugins, zelfde soort content. Elke wijziging gaat eerst daarheen: de update wordt gedraaid, de aanpassing gebouwd, en vervolgens wordt er gecontroleerd of alles nog werkt. Het formulier, de checkout, het menu, de belangrijkste pagina’s. Pas als dat klopt, gaat dezelfde wijziging gecontroleerd naar de live site.
Voor grotere projecten komt er nog een laag bij: een aparte ontwikkelomgeving waar gebouwd wordt, met versiebeheer eronder zodat elke wijziging is terug te draaien en terug te lezen. Maar voor de meeste sites is het principe belangrijker dan het aantal lagen: er zit altijd een controlemoment tussen “gemaakt” en “live”.
Wat het je oplevert
Het directe voordeel is duidelijk: geen verrassingen op de live site. Maar er zijn er meer. Updates worden niet meer uitgesteld uit angst dat er iets breekt, en uitgestelde updates zijn, zoals we schreven in ons artikel over gehackte sites, het grootste beveiligingsrisico dat er is. Grotere aanpassingen kunnen rustig worden voorbereid en op een gekozen moment live gaan, in plaats van half af op de site te staan. En de opdrachtgever kan meekijken: een nieuwe functie eerst zelf proberen op de testomgeving voordat klanten hem zien.
Er zit ook een omgekeerde les in. Als je huidige partij aanpassingen gewoon rechtstreeks op de live site doet, is dat een teken over de rest van de werkwijze. Vraag er gerust naar; het antwoord zegt veel, net als de andere vragen uit ons artikel over het kiezen van een webbureau.
En het kopietje moet wel kloppen
Eén valkuil verdient een eerlijke vermelding: een testomgeving die maanden achterloopt op de live site, test niets. De kopie moet actueel zijn, anders test je tegen een site die niet meer bestaat. Goede beheerpartijen verversen de testomgeving daarom automatisch of vlak voor elke wijziging. En let op de afscherming: een testomgeving die zomaar vindbaar is voor Google, gaat concurreren met je echte site in de zoekresultaten. Ook dat hoort gewoon geregeld te zijn.
Bij Digital Dreamers is dit geen optie maar de standaard: elke site die wij beheren heeft een testomgeving, en elke wijziging, hoe klein ook, gaat daar eerst doorheen. Het kost per wijziging een paar minuten extra. Het bespaart per jaar de ene keer dat het anders goed mis was gegaan. Die ruil winnen we graag, elke week opnieuw.
